Automatically add imagePullSecrets to a ServiceAccount

user_872848 0
Viewed 10586

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.]

kubernetes
5 Answers

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"}]}'
user_89715070

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).

user_59302950

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.

user_8728480

You can do that in three steps:

CREATION OF SECRET 

kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

CREATION OF SERVICE ACCOUNT (here you bind the secret)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: chicken 
imagePullSecrets:
- name: myregistrykey

CREATION OF ROLEBINDING (here you bind serviceAccount and Role)

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: example-rolebinding
  namespace: mynamespace
subjects:
- kind: ServiceAccount
  name: chicken
  namespace: mynamespace
roleRef:
  kind: Role
  name: example-role
  apiGroup: rbac.authorization.k8s.io
user_27181510

AFAIK. The only thing that you can do is associate different ImagePullSecrets with different namespaces and then restrict the access of the user to only that namespace. This is so that those users can use those secrets to create Deployments/DaemonSets/StateFulSets/Pods.

But then possibly you run into the problem of having too many namespaces.

user_29892610
Related