Bug 1303009

Today, service accounts are a mechanism for subdividing access rights within pods, for any entity in a pod that must act back to the API.  They are also a mechanism for subdividing access to cluster permissions (via SCC).  Enforcement is done by the other actors in the system (for instance, the build controller runs as an entity entitled to create pods with certain privileges across the entire cluster), and sometimes that enforcement is done "on-behalf-of" by verifying that the owning entity (the service account) is itself entitled to that action.

The request seems to center around two needs:

* limit end users within a project to the set of permissions to their roles
* allow them to continue to create secrets

If the end user in question could not view secrets that they are not entitled to, would that suffice?  For instance, if the end user could create and manage secrets, but only in the context of a specific service account, then there could be no escalation (the user cannot see the system service account secrets like builder and deployer) and

Not sure if i understood this. Our main goal is to prevent users to read dedicated account sensitive data, so if they need to use any CI&CD tools, they would create their own secret. But at the same time Build process would not be impacted, so if namespace builder account would be able to build and so forth...

We could define build, deploy as a separate "permission". User can build, deploy, but he cant take builders account secret and add it to his Jenkins instance and use it for remote building as this will invalidate Role based access, as we will not be able to track who did this.

Regarding the initial comment: it is possible to specify a resource name on a policy rule: https://docs.openshift.org/latest/rest_api/openshift_v1.html#v1-policyrule .

That restriction makes it possible enumerate exactly which resources can be directly retrieved, but you should keep in mind that we don't restrict which SAs can be used on a given Pod.  This allows a clever user with the power to create something that can lead to a pod, to craft a PodSpec that uses an SA, harvests its automounted secret (or any secret that SA is allowed to mount, again by guessing), and exposes it to learn any secret in the same namespace.

To address this risk, we keep important secrets in namespaces that regular users cannot access.  Things like the builder and deployer exist in the `openshift-infra` namespace.  If you segment secure access on namespace, I think your situation will be easier to reason about.

@ederevea

Given the above comments, is there still a remaining request here?

Do we have any example how this can be used to control (limit) access to SA?

https://bugzilla.redhat.com/show_bug.cgi?id=1303009#c4 points to documentation showing how to craft a role that only allows access to a service account with a particular name.

However, as it points out, giving someone permission to create pods and run images of their own choosing in a namespace will let them gain access to API tokens for service accounts in that namespace, so care would need to be taken to not give those permissions (or any that allow triggering pod creation, like creating/updating replication controllers, builds, deploymentconfigs, etc).