We're making use of ServiceAccounts for RBAC, and so have multiple SAs in play to allow us us to tune accesses via RoleBindings appropriately.
We're also using a private registry, and thus have imagePullSecrets to use for pulling images from the private registry. I'm trying to come up with a solution by which all SAs created within a namespace would by default get the list of imagePullSecrets applied to the default SA added to them, so that when we deploy the pods making use of the service (typically right after the SA), the serviceAccount is already configured to use the imagePullSecrets to retrieve the images.
Has anyone devised an elegant way to handle this? I did check to see whether pods could have more than one serviceAccount applied - N to hold imageSecrets, and 1 to map to RBAC. And/or, can someone suggest an alternate way to look at the problem?
[UPDATE: Clarifying - the challenge is to share the set of imagePullSecrets across multiple service accounts, preferably without explicitly needing to add them to each ServiceAccount definition. The private registry should be considered akin to dockerhub: the user accessing the registry is generally intended to be able to pull, with the user info then used to track who's pulling images and occasionally to keep users from pulling images they shouldn't have access to for 'this thing just isn't intended for broader consumption' reasons.]
Use more than one ServiceAccount To use a non-default service account, set the spec.serviceAccountName field of a Pod to the name of the ServiceAccount you wish to use. You can only set the serviceAccountName field when creating a Pod, or in a template for a new Pod.
Secrets can be mounted as data volumes or exposed as environment variables to be used by a container in a Pod. Secrets can also be used by other parts of the system, without being directly exposed to the Pod.
To obtain the token, you need to create a service account (ServiceAccount) and associate it with the cluster role. Each created service account will have a token stored in the Kubernetes Secret API. The updated kubeconfig will be located in the $HOME/. kube/config home directory.
As I answered in another thread:
To easily add imagePullSecrets to a serviceAccount you can use the patch command:
kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "mySecret"}]}'
It has been said before, there is no standard kubernetes way to globally define private registry secrets at cluster level. The solutions mentioned above only are all but great. Other proposals (i.e. here), I also found unsatisfactory.
What is needed is the possibility to define a private registry secret once and use it as imagePullSecrets
for every ServiceAccount.
Titansoft's magepullsecret-patcher can just do that. It populates a provided image pull secret accross all namespaces and patches all ServiceAccounts to use the secret as their imagePullSecret
. However, Titansoft's magepullsecret-patcher only works with one private registry secret.
In my use case, I have multiple private container registries for which I want to give access to in all my cluster's namespaces.
Hence, I use neutryno's imagepullsecret-serviceaccount-patcher approach. It makes use of mittwald's kubernetes-replicator for replicating private registry secrets across all namespaces. On top of that, neutryno's imagepullsecret-serviceaccount-patcher patches all service accounts' imagePullSecrets
to include the defined private registry secrets (<- yes multiple if you wish).
Recording the resolution which seems to work for us:
Stash the text for the imagePullSecrets list in a variable, and then use that variable in our templates for ServiceAccounts. If no private registries, the variable is an empty string. If there are private registries, then the variable contains
imagePullSecrets:
- name: secret1
- name: secret2
(etc, etc) We're working within an Ansible environment, and so able to take advantage of Jinja templates, but I think the approach would generally apply.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With