SPIKE - Default Permissions for RHEL Entitlement Share

Spike User Stories

As a developer building applications on OpenShift
I want to have access to RHEL subscription content in builds
So that I can install RPMs in my application which require a Red Hat subscription

As a cluster admin with 3rd party tenant users
I do not want to expose my RHEL content access certificate to users
So that third parties use my certificate to access RHEL content in violation of our contract with Red Hat.

As a cluster administrator
I want to control which namespaces and service accounts have access to the RHEL content access certificate
So that only users with permission to consume RHEL content can do so.

Acceptance Criteria

Answer the following:

1. Should we have a well known `SharedSecret` which is created along with the cluster simple content access certificate? Not by default, this should require some form of config to be set to true.
2. Should there be default RBAC associated with this `SharedSecret`? For instance, should all `builder` service accounts have permission to use the well known `SharedSecret`? Not by default, though there should be some form of config to set this to true.
3. If yes to 1 and 2, which component(s) should be responsible for creating the well known secret and associated RBAC? TBD, likely a combination of the Insights Operator and openshift-controller-manager-operator.

We need to update our EPs for subscription content access so the process is clear and coherent.

Docs Impact

None

PX Impact

None

QE Impact

None

Notes

Some customers run OpenShift as a service for other users (multi-tenant). Their entitlement should not be shared by default since the entitlement does not belong to the end user.

The creation of the `SharedSecret` that exposes the simple content access certificate should be a day 2 action. Similar story with creating the RBAC for all builder service accounts. The Insights operator has configuration which prevents the downloading of the SCA certificate - this is something we can take advantage of or build on top of.

Safest course is to ensure that this capability is opt-in. The global opt in process should be simple - for example, changing an OpenShift cluster config API.
We should also have a "plan B" approach where service accounts can opt into using the SharedSecret on a namespace/service account level.