You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem
When an aks cluster is setup with EntraId Auth and Azure RBAC you need to pass "extra:oid" in order for impersonation to work. This means weave gitops' impersonation will not work. Example:
Error from server (Forbidden): gitrepositories.source.toolkit.fluxcd.io is forbidden: User "[email protected]" cannot list resource "gitrepositories" in API group "source.toolkit.fluxcd.io" at the cluster scope: Azure does not have opinion for this non AAD user. If you are an AAD user, please set Extra:oid parameter for impersonated user in the kubeconfig
along with the normal user config and use it the (via a new context) it works
Solution
I'd like a feature to be able to map oidc claims to impersonation extras
Workaround
I added oidcGroupsPrefix: "weave:" to my issuer secret then manually configured RBAC for specific groups using things like the following yaml. Not ideal since the whole point of using Azure RBAC is to centralize this sort of thing
Simple implementation could accept a set of keys to lookup in the OIDC ID Token and store these on the UserPrincipal as a map.
It's a bit tricky because the values for the the Extra data are slices of strings, so, similar to the existing code, you'd need to parse these as strings or slices of strings, and convert the string to a slice when necessary.
Problem
When an aks cluster is setup with EntraId Auth and Azure RBAC you need to pass "extra:oid" in order for impersonation to work. This means weave gitops' impersonation will not work. Example:
Results in
If you create a user in your kubeconfig with
along with the normal user config and use it the (via a new context) it works
Solution
I'd like a feature to be able to map oidc claims to impersonation extras
Workaround
I added
oidcGroupsPrefix: "weave:"
to my issuer secret then manually configured RBAC for specific groups using things like the following yaml. Not ideal since the whole point of using Azure RBAC is to centralize this sort of thingAdditional context
The text was updated successfully, but these errors were encountered: