Bug 1303009 - [RFE] Access Limitation to Individual serviceaccounts/secrets
[RFE] Access Limitation to Individual serviceaccounts/secrets
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE (Show other bugs)
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Jordan Liggitt
Johnny Liu
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2016-01-29 04:47 EST by Evgheni Dereveanchin
Modified: 2018-02-23 12:54 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2018-02-23 12:54:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Evgheni Dereveanchin 2016-01-29 04:47:27 EST
Description of request:
Currently OpenShift users are either allowed to view/modify all serviceaccounts and secrets for the project, or none of them. This request proposes adding access controls as to add access restrictions for users to specify which secrets/serviceaccounts can be accessed,modified,etc

Version-Release number of selected component (if applicable):

Example of desired ACL:

  - serviceaccounts/deployer
  - serviceaccounts/builder
- serviceaccounts/serviceCustom
  - list
  - watch
Comment 2 Clayton Coleman 2016-02-07 14:36:00 EST
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
Comment 3 Mangirdas 2016-02-19 02:12:34 EST
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.
Comment 4 David Eads 2016-04-13 10:46:41 EDT
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.
Comment 5 Dan McPherson 2016-04-14 09:43:51 EDT

Given the above comments, is there still a remaining request here?
Comment 7 Mangirdas 2016-05-02 03:32:21 EDT
Do we have any example how this can be used to control (limit) access to SA?
Comment 11 Jordan Liggitt 2016-05-09 10:06:00 EDT
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).

Note You need to log in before you can comment on or make changes to this bug.