Is it possible to temporarily disable Azure Active Directory RBAC in Azure Kubernetes Service? The reason I ask is because we are unable to set up automated tasks (like continuous integration) because authenticating against kubectl now requires human intervention to complete device code auth - I have another post here regarding that. Perhaps even just disabling Kubernetes RBAC will bypass the need to authenticate with AD? I would do this until a solution to the issue is available.
Although there is no document exactly say that you cannot disable the RBAC of an existing AKS cluster. But it shows that enabling role-based access control (RBAC) on existing clusters isn't supported at this time. In my opinion, it also means that you cannot disable the RBAC on existing AKS cluster. And it seems there is no way to achieve it, no matter Azure CLI, PowerShell or REST API.
I think the RBAC is a setting for AKS cluster and it could not be changed after it created now. We can expect that it could be changed in the future. Hope this will help you.
Related
I have Azure Databricks workspace hidden inside VNET and configured with Private Link, following instruction from Microsoft.
Now I'm trying to do SCIM provisioning with this workspace and I'm getting following error.
When I tried with workspace without Private Link then everything works fine.
Is there any solution to use SCIM provisioning with workspace which has Azure Private Link configured?
Azure AD's SaaS Application SCIM provisioning service requires internet-accessible endpoints. Your usage of the Private Link feature isn't going to play nicely with that, given the endpoint isn't internet accessible.
This feature may help, though: https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/on-premises-scim-provisioning
In a nutshell, it allows you to do SCIM provisioning via an agent (hosted on a server that IS internet accessible), which can then talk to other non-internet accessible servers on the same network. You'll have to use the generic SCIM provisioning features here and may need to customize some attribute mappings as a result, as the Databricks-tailored gallery app is only available for internet-facing instances of Databricks at this time. Beyond that, I think the on-premises provisioning feature should help here.
One option could be to set publicNetworkAccess to true to be able to access the control plane both publicly and via private endpoint. I guess the provisioning service would be able to talk to the Databricks control plane that way.
Now the downside is that, well, your control plane could be accessed publicly. But you could mitigate that by imposing a conditional access policy in your Azure AD tenant to force all authentication callbacks to originate from your own VNets.
I've been working with EKS and GKE and in both places they have a formal, streamlined manner of ensuring a pod comes up with the necessary credentials for a "role" in the cloud's rbac system (IAM Role for AWS, Service Account in GCP) via K8's native service accounts. This makes integration with other of the host cloud's services quite easy. I'm now trying to do the same in AKS but I don't see any such integration for their respective rbac. Am I missing something badly? How do you do it?
I want to first audit (and later enforce) that user names added to a specific AD Group follow certain naming convention. Is this achievable via Azure Policy? It would be straightforward to get such report through scripting, but in our case we want to see clear audit status with Azure policies and eventually prevent them from being added in the first place with Policy deny effect.
No, I believe Azure Policy can only be used on the Azure Resource Manager scope. Azure AD objects like users and groups can't be managed using Azure Policy. So one way to think of it is that if you can deploy something with an ARM template, you can likely govern only those objects using Azure Policy.
The alternative to having nice audit reports for Azure AD stuff would be Azure AD Privileged Identity Management (PIM). It's pretty awesome but I don't think your use case around enforcing and auditing naming conventions of users is supported. Cheers!
I know with Azure Kubernetes service we can use managed identities to access azure resources like keyvaults. But i'm trying to learn if same procedure can be applied to a kubernetes cluster which is hosted on azure. My aim is to have kubernetes cluster in azure with 2 worker and 2 controller nodes but pods residing on those nodes should access azure keyvault with managed identity method similar to AKS. Is there anyway we can do it without coding in application?
I understand the scope of this question is big but it is really helpful if somebody provide any high level steps ?
thanks,
Santosh
That's totally possible. AAD Pod identities rely on AAD (Azure Active Directory) and its permissions.
At the end AKS will have an infrastructure behind the scenes. So if you plan to not use AKS but install a cluster by yourself, for example with AKS engine, you can use AAD Pod Identities / Managed Instances.
All you need is that those machines reside in "Azure" and rely on what is called Azure Instance Metadata Service (IMDS). Even you can enroll new machine instances coming outside from Azure with the project ARC. Anyway I cannot talk about it with Managed instances since I have not used it, anyway it should follow a similar pattern.
Here you have a good article that explains AAD Pod identities:
https://itnext.io/the-right-way-of-accessing-azure-services-from-inside-your-azure-kubernetes-cluster-14a335767680
I have some Azure Functions that I share to my partner companies who then run the Azure Functions in their own Azure subscriptions.
Occasionally the partners run into issues and reach out to me for help. I have to instruct them to manually pull the Azure Function logs and send to me via email.
Is there anyway they can grant me permission to pull the logs from their Azure Subscription?
It depends on where you have the logs.
Either way, they can grant you RBAC permission to their resource in their subscription. Generally, they have read only access options available. All resources have the same experience for modifying RBAC (but they do differ on which policies they support). It's pretty straightforward, but this doc has more information: https://learn.microsoft.com/en-us/azure/active-directory/role-based-access-control-configure
If you're using our default Storage logs, do yourself a favor and turn on App Insights because it's great. Then, if you still want to use Storage, you can get RBAC access or a SAS token and grab those logs from the Storage Account associated with the Function App. (Name should be in the AzureWebJobsDashboard setting). If you get a SAS token, you can use the Storage Explorer by choosing the SAS URI option when you connect.
If you're using App Insights, good job, you've made the right decision. You can get RBAC access to the App Insights resource and use all their great UI experience/etc. You can also get an API Key and make direct API calls against it, in the case that RBAC wouldn't work. (I would try to get RBAC access, but if that's not possible, here's a link to App Insights REST API docs: https://dev.applicationinsights.io/quickstart)
Short answer, use RBAC to get granted limited permissions (and App Insights because it's great)