kubeguard / guard

🔑 Kubernetes Authentication & Authorization WebHook Server
https://kubeguard.dev
Apache License 2.0
590 stars 81 forks source link

KubeGuard is blocking built in service accounts from taking action with roles assigned inside of AKS #345

Closed joshuadmatthews closed 1 year ago

joshuadmatthews commented 1 year ago

have an AKS cluster configured with enableAzureRBAC=true

I am trying to install the ingress-nginx Helm chart through Flux

It throws the error

reconciliation failed: failed to get last release revision: query: failed to query with labels: secrets is forbidden: User "system:serviceaccount:default:flux-applier" cannot list resource "secrets" in API group "" in the namespace "default": Azure does not have opinion for this user.

I can see that flux sets up a clusterrolebinding to make the flux-applier a cluster admin, which I have verified is in place


Name:         flux-applier-binding
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  cluster-admin
Subjects:
  Kind            Name          Namespace

  ----            ----          ---------
  ServiceAccount  flux-applier  flux-system

So I assume my issue is that Azure doesn't recognize this ServiceAccount and it isn't falling back to built in roles?

https://github.com/kubeguard/guard/blob/master/authz/providers/azure/rbac/checkaccessreqhelper.go

The Azure docs on Azure RBAC for AKS clearly state:

If the identity making the request exists in Azure AD, Azure will team with Kubernetes RBAC to authorize the request. If the identity exists outside of Azure AD (i.e., a Kubernetes service account), authorization will defer to the normal Kubernetes RBAC.

https://learn.microsoft.com/en-us/azure/aks/concepts-identity

But this doesn't seem to be true?