admission denies cluster-admin from exec into build pod #16092
Comments
stevekuznetsov
added
area/security
area/usability
kind/bug
|
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 |
stevekuznetsov
changed the title
|
/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 execinto a build pod I see this:Running on the CI cluster:
oc get sccoc exec kube-state-metrics-binary-10-build --as system:admin --loglevel 9001 -- lsoc get pod kube-state-metrics-binary-10-build -o yamlThe text was updated successfully, but these errors were encountered: