-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
admission denies cluster-admin from exec into build pod #16092
Comments
Also FWIW this is the current UX of this command:
That is 100x impossible to read. |
/cc @pweil- |
/cc @bparees for good measure since it's a build pod |
/unassign @enj @php-coder this looks like maybe it could have to do with impersonation and how that comes across in the admission chain. In practice, the cluster-admin should be able to exec into anything because they are granted the privileged SCC by default but here it looks like only the restricted provider is available. |
Most likely there is something that was broke in the authentication/impersonation because admission controller hasn't been changed recently. |
How can we validate? What do you need to see for debugging? |
@php-coder you can up the log level to at least 4 and test the difference of the user info before and after the authentication changes when using an |
Based on my debugging session my theory is that earlier impersonated user had a populated Also I see that now the user has |
@php-coder what is the user info (all fields) during admission:
For both 3.6 and master (4 values total). |
I tried 3.6 and it also didn't work but fails with another error: #13390 So, let's assume that it's never worked. |
Here is the code for deciding whether a user has access to SCC or he's not: origin/pkg/security/securitycontextconstraints/matcher.go Lines 54 to 68 in 047c984
In order to allow user in
How it's supposed to work? CC @deads2k |
For the history:
|
I couldn't make impersonation work at all. User that has
|
I found a workaround:
|
When I impersonate the user, I only get the privilege they have themselves, not from their groups? That is surprising. |
Yes, in this case you also need to specify
Indeed. |
The UX of this is worse than terrible. Can we make it default to also grab groups? |
In order to improve UX (and do not surprise even seasoned developers) I suggest to grant the @openshift/sig-security Objections? |
No, the groups are determined by the auth method, and are not available for lookup to the impersonation filter. |
$ oc exec ruby-hello-world-1-build --as system:admin --as-group system:cluster-admins -- pwd
Error from server (Forbidden): User "developer" cannot "impersonate" "systemgroups.user.openshift.io" with name "system:cluster-admins" in project "" Seems like users from |
Is what you really want to add |
The following patch could fix it: --- pkg/cmd/server/bootstrappolicy/policy.go
+++ pkg/cmd/server/bootstrappolicy/policy.go
@@ -135,7 +135,7 @@ func GetOpenshiftBootstrapClusterRoles() []rbac.ClusterRole {
Name: SudoerRoleName,
},
Rules: []rbac.PolicyRule{
- rbac.NewRule("impersonate").Groups(userGroup, legacyUserGroup).Resources(authorizationapi.SystemUserResource).Names(SystemAdminUsername).RuleOrDie(),
+ rbac.NewRule("impersonate").Groups(userGroup, legacyUserGroup).Resources(authorizationapi.SystemUserResource, authorizationapi.SystemGroupResource).Names(SystemAdminUsername, ClusterAdminGroup).RuleOrDie(),
},
},
{ |
So to be explicit,
And add Sound good? |
this one is unnecessary. Otherwise, yes. |
system:masters is a "magic" group that always has full access to do anything. There is a special authorizer that allows it. system:cluster-admins seemed like a good idea at the time. It isn't special. |
@php-coder I was mostly trying to make the UX as nice as possible. Thus you want:
And add |
There is some stuff in https://kubernetes.io/docs/admin/authorization/rbac but yeah it probably deserves some information. |
Automatic merge from submit-queue Modify "sudoer" group and "privileged" SCC to seamlessly work together Prior this change, a member of "sudoer" group couldn't create a privileged pod (or perform `oc exec` against it). Also before, a user couldn't impersonate `system:masters` group. Now all of these are became possible. PTAL @openshift/sig-security Fixes #16092
Trying to
oc exec
into a build pod I see this:Running on the CI cluster:
oc get scc
oc exec kube-state-metrics-binary-10-build --as system:admin --loglevel 9001 -- ls
oc get pod kube-state-metrics-binary-10-build -o yaml
The text was updated successfully, but these errors were encountered: