Azure-docs: rolebinding to a service principal instead of user or group

[bramvdklinkenberg]

Instead of binding a role to a user or group, can I also bind it to a service principal?
If we want to do deployment from vsts and you need to log in first manually that won't work. The only way to be able to directly login with the az cli is with a service principal. And I want to bind a role that only gives access to a specific namespace.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a47c6df7-5103-1336-eb0b-68f95155e6c8
• Version Independent ID: f4420b08-9b57-f581-fcb4-f069afdd5b0c
• Content: Integrate Azure Active Directory with Azure Kubernetes Service
• Content Source: articles/aks/aad-integration.md
• Service: container-service
• GitHub Login: @neilpeterson
• Microsoft Alias: nepeters

[mimckitt]

Thanks for the feedback! We are currently investigating and will update you shortly.

[mimckitt]

@neilpeterson do you know the answer to this one?

Seeing as this feature is in preview I would not be surprised if this is not possible. But in theory I could also see it working... :)

[mimckitt]

@bramvdklinkenberg we have been having some internal discussions and we believe mapping RBAC to a service principle should be possible. However, no one has actually tested this yet! So as per specific instructions is something we do not have yet. We will be testing this out sometime next week to fully verify. In the meantime, feel free to give it a go as it should work. But also make sure to do at your own risk if this is a production environment as it is not been a fully tested scenario yet

[bramvdklinkenberg]

Hi @MicahMcKittrick-MSFT , I will try it this week!
KR,
Bram

[mimckitt]

@bramvdklinkenberg great! I will close this out for now. But if you hit issues feel free to come back here and we can investigate and get it sorted out.

[timwebster9]

@bramvdklinkenberg did you get this to work? I'm looking at something similar. If so, could you share sample config? :-)

[bramvdklinkenberg]

Hi @timwebster9 , I tried but couldn't get it to work yet:

The RoleBinding "sp-admin" is invalid: subjects[0].kind: Unsupported value: "ServicePrincipal": supported values: "ServiceAccount", "User", "Group"

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: sp-admin
namespace: bram
rules:

• apiGroups:
  
  
  
  • ''
    
    resources:
  
  
  • ''
    
    verbs:
  
  

- '*'

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: sp-admin
namespace: bram
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: sp-admin
subjects:

• apiGroup: rbac.authorization.k8s.io
  kind: ServicePrincipal
  name: "

[timwebster9]

@bramvdklinkenberg thanks for the reply. Have you tried leaving it as 'User' instead of 'ServicePrincipal' and using the SP id? At least in the Azure AD UI the SP ID can be used in the place of a user.

[bramvdklinkenberg]

Sorry for the late reply. So I did the following:

• Gave a service principal contributor rights on the resource group of the AKS cluster
• Created a namespace, a role and rolebinding. In the rolebinding for subject I used user as kind and added the object id of the SP as name.
• I logged in with the SP id
• Did a get-credentials

With the config file for the SP user I can (still) see everything.

[mimckitt]

Thanks for the update @bramvdklinkenberg

To confirm, did this work or still a no go?

[bramvdklinkenberg]

Hi @MicahMcKittrick-MSFT , no because when logged in with the SP I can see everything on the cluster een though it should only see a specific namespace.

[bramvdklinkenberg]

Maybe I am doing somehting wrong though. What permissions does a user at least need on the resource/ resource group to be able to do a az aks get-credentials? I think it is cotributor rights, right?
So I gave the SP contributor rights on the RG. Created a cluster with a new namespace and created a role with all rights on that namespace and in the rolebinding I used the SP object ID as value for the subjects name and used user for kind.

[smartpcr]

I am also interested in using ServicePrincipal ObjId as user in AKS role binding, also if it's possible to run pod as user (aad service principal) instead of service account. please let me know how it goes. Thanks!

[mimckitt]

@iainfoulds @mmacy would either of you have any contacts that could help further on this?

[iainfoulds]

This is a known request in the engineering backlog. I don't have any update as yet on this. I'll follow up with the engineering team to see if there's anything more to share.

[mimckitt]

Thanks @iainfoulds! Appreciate it :)

[iainfoulds]

I haven't tried this yet, but the suggestion from engineering would be to create a Kubernetes service account, rather than binding to the service principal. That Kubernetes service account should then be something that can be provided to a VSTS build pipeline.

@bramvdklinkenberg As there's quite some back-and-forth - what's the actual ask/request here? Would binding to a Kubernetes service account work for your scenario?

[bramvdklinkenberg]

Hi @iainfoulds ,
We have some generic clusters where several teams are onboarded and do their thing within their own namespace. So for them to only have access to their namespace I created rolebindigs according to this page.
A rolebinding for user of ad group is fine when you work with kubectl locally, they can get their own config file specific for their account. But we don't want to use peoples config file in deployment pipelines. And logging in with a username also has the disadvantage what we have mfa, and we don;t want the cd pipeline asking for someone to fill a text message to authenticate. That is why I was looking for a rolebinding a service principal.
I don't know if I can accomplish the same with a service account?! Can I create a kubeconfig file for a service account?

[iainfoulds]

I don't believe service accounts can pull the kubeconfig using az aks get-credentials as those accounts only exist within Kubernetes. The Azure CLI would be unaware of them. The suggestion on service accounts is more for those automation solutions and pipelines that require access to creating or managing cluster resources. You'd continue to use AAD-integration and bindings when individuals need to interact with the cluster, but for any of the automation tools, you'd use service accounts. This also provides a clear audit trail as to which user manually performed a task, or which service account (maybe one for each automation pipeline) did so.

[mimckitt]

Thanks @iainfoulds

@bramvdklinkenberg does that help clarify the ask?

[mimckitt]

@bramvdklinkenberg I will close this for now. If you want to continue the discussion just let me know and we can always reopen and continue.

[timwebster9]

@iainfoulds if using a service account for pipelines, how would you recommend authenticating with the cluster? I believe you would have to have a kubectl config file containing the server certificate and all that stuff.

We have a similar setup to @bramvdklinkenberg. I considered using service accounts but one of the things I want to avoid is having to distribute kube config files and credentials - it's just another configuration management headache, especially if they all need to be recreated if the cluster itself is recreated (which will happen). Being able to use the azure cli to authenticate is one of the nice things about AKS in my opinion, but we lose that if we try to then introduce some access control.

If using service accounts is the recommended solution, then it would maybe help if that was added to the docs (along with some examples of how to handle the config/authentication).

In the meantime I've raised this issue in the feedback forum: https://feedback.azure.com/forums/914020-azure-kubernetes-service-aks/suggestions/35146387-support-non-interactive-login-for-aad-integrated-c

[bramvdklinkenberg]

Hi @MicahMcKittrick-MSFT , sorry for the delayed reply. Like @timwebster9 says I don't want to be creating kubeconfig files for service accounts manually and storing/saving those. The ease of the az cli and using a service principal takes all that away.

[razidare]

@MicahMcKittrick-MSFT Hello. We're having a similar issue:

Our plan is to have automated application deployment pipelines from Azure DevOps to AKS, and there were no issues so far until we enabled RBAC on our AKS cluster to achieve granularity of access/rights.

Now, we as users, get to login with az cli when issuing kubectl commands, but the VSTS agents won't be able to do so and as the guys specified above. Using a service account and creating configs for that is cumbersome. Has any other development been done on this ask?

@timwebster9 @bramvdklinkenberg Did you guys find any workaround to this still present issue?

[timwebster9]

@razidare nope - still just using az cli. You can still do this in VSTS with the Kubernetes deploy task and a service connection, so that shouldn't block you (unless you have some other specific restrictions you haven't mentioned).