installing packages with dependencies from private registry

[jbw976]

What's Missing?

The challenge of installing a package from a private registry that has further dependencies (e.g. family providers) recently came up in:

• missing family dependency for custom provider crossplane#5799 (comment).

We have some existing docs for this scenario, but they are not quite complete:

• https://docs.crossplane.io/latest/concepts/providers/#install-a-provider-from-a-private-registry
• https://docs.crossplane.io/latest/concepts/packages/#install-a-configuration-from-a-private-registry

The provider focused page mentions this challenge, but does not provide a solution for it:

Configured packagePullSecrets aren’t passed to any Provider package dependencies.

As @turkenh suggested in crossplane/crossplane#5799 (comment), one solution is to provide package pull secrets at the Crossplane service account level instead of to individual packages. We could document this approach so it is more discoverable for folks using private registries.

[jeanduplessis]

The downside of the current solution for patching the Crossplane ServiceAccount with the pull secret, other than it being a shared secret for all packages, is that it will disappear (i.e. reset) when you upgrade Crossplane.

Possible solutions we have been thinking about:

• Option A: Fix workaround, upgrading Crossplane, not resetting SA (not sure if it is possible/feasible even)
• Option B: Flow parent packagePullSecrets down to their dependencies. This feels like the most intuitive solution, but there are caveats. We would be passing credentials to public dependencies as well. Or, if a package is a dependency for multiple parents, would it get secrets from all, etc.?
• Option C: Extend package installation API to somehow be able to pass pull secrets to each dependency separately.
• Option D: Add a new api for configuring the package manager to use private pull secrets per registry

[turkenh]

Re: Option A - I had a closer look how we deploy Crossplane’s SA and realized that we already have a helm value to inject imagePullSecrets with helm install/upgrade commands. This means that, the pull secrets users provide would not be reset if it were provided via helm upgrade --install crossplane … --set imagePullSecrets={secret1,secret2…} instead of manually patching SA after the installation. So, this solution should already work with this little caveat.

This means we could still leverage / rely on this option as a stop gap solution for private images/dependencies. It is a little inconvenient for folks to run an upgrade command instead of simply patching existing SA, but for any serious non-development cluster, people use GitOps like flows to install Crossplane and this would be one additional line there.