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
For the static client dex-k8s-authenticator this is fine, but for weave-gitops-dashboard this is not what I want because API requests from the application are made by the cluster admin role (the k8s-admins group has a crb for the cluster admin role)
"impersonatedUser": {
"username": "oidc:dm",
"groups": [
"oidc:k8s-admins",
"oidc:grafana-admins",
"oidc:gitea-admins",
"oidc:vault-sops",
"oidc:vault-admins",
"oidc:flux-admins",
"system:authenticated"
]
},
"annotations": {
"authorization.k8s.io/decision": "allow",
"authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"oidc-clusteradmin-group-k8s-admins\" of ClusterRole \"cluster-admin\" to Group \"oidc:k8s-admins\""
}
I don't want the application to use the cluster admin role. If the token for the weave-gitops-dashboard client will only have
"groups": [
"flux-admins"
],
everything will be ok
authorization.k8s.io/reason": "RBAC: allowed by ClusterRoleBinding \"oidc:wego-admin-cluster-role:group:flux-admins\" of ClusterRole \"wego-admin-cluster-role\" to Group \"oidc:flux-admins\""
Hello, I opened this PR a couple of years ago #1583. It looks similar to what you are asking.
However, this approach was marked as needing to be more generic. In my company, we are still living with the patch.
I'd like to have something like authenticationPolicy or tokenClaimValidation to provide a set of expressions to validate each token against. In Kubernetes, we use CEL for this purpose, but I believe a structured config with a predefined set of validation actions will be enough.
Hello, I opened this PR a couple of years ago #1583. It looks similar to what you are asking.
However, this approach was marked as needing to be more generic. In my company, we are still living with the patch.
I'd like to have something like authenticationPolicy or tokenClaimValidation to provide a set of expressions to validate each token against. In Kubernetes, we use CEL for this purpose, but I believe a structured config with a predefined set of validation actions will be enough.
Hello, yes, this is exactly what I need. It's sad that this PR is still unmerged.
Preflight Checklist
Problem Description
It would be useful to filter the groups that would be returned in the oidc token from the dex.
For example, I have 2 static clients
My use case is an application https://docs.gitops.weave.works/docs/configuration/service-account-permissions/#impersonation using k8s impersonation. And when I log into weave-gitops-dashboard through the OIDC provider (dex), I get a token with the full list of groups.
yes, this is expected behavior
For the static client dex-k8s-authenticator this is fine, but for weave-gitops-dashboard this is not what I want because API requests from the application are made by the cluster admin role (the k8s-admins group has a crb for the cluster admin role)
I don't want the application to use the cluster admin role. If the token for the weave-gitops-dashboard client will only have
everything will be ok
Proposed Solution
Add group filters to static clients configuration
Alternatives Considered
No response
Additional Information
No response
The text was updated successfully, but these errors were encountered: