Epic Goal

• Allow pull secrets to be specified by cluster admins for operators in a single place
• Automate pull secret propagation and assignment to deployed operators
• Extend current pull secret support for catalog and bundle images to operators (not operands)

Why is this important?

• Nightlies, release candidates and hotfix builds of operators are often hosted on authenticated registries (private repos), thus requiring a pull secret to be present on the cluster for the right service accounts to use
• Pull secret handling is currently implemented at the catalog level and covers pulling private catalog and bundle images. Operator controller images are not handled.
• cluster admins are forced to prepare pull secrets in operator deployment namespaces and pre-create service accounts that align with the operator deployment to references those pull secrets
• this is extremely complex as it requires intimate knowledge of the operator and requires that the operator's use of service accounts is monitored over time
• Doing this with the global pull secret allows cluster wide access (all tenants) to those private images
• Applying global pull secrets is hard to monitor and can lead to timing issues
• Overwriting the global cluster pull secret on a frequent basis is prone to race conditions

Scenarios

1. An operator team mirrors operators into a catalog on an authenticated registry, a pull secret is required to pull catalog, bundle and operator controller images
2. A cluster admin configures the secrets at the CatalogSource level which triggers OLMs secret propagation to service accounts that are used for pulling catalog and bundle images
3. When the cluster admin deploys an operator from this catalog, OLM copies the pull secret referenced at the CatalogSource in the namespace of the Subscription 
4. OLM then associates the previously created pull secret with all ServiceAccounts associated with Deployments from the operator bundle

Acceptance Criteria

• Existing pull secret API of CatalogSource is used
• All referenced pull secrets of a CatalogSource are automatically propagated to operator Deployments without user intervention
• Referenced pull secrets are cleaned up upon operator removal
• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ...

Dependencies (internal and external)

1. MT-SRE

Out of scope (Optional):

1. Operand pull secret propagation

Open questions:

1. Should the SDK define helper facilities to help with pull secret propagation to operands?

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>