K
Q

Automatically add imagePullSecrets to a ServiceAccount

9/13/2018

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

-- TinaC
kubernetes

Similar Questions

azure cni NATing to DST node address
Kubernetes on VPS with public and private NICs
Launch a pod in k8s to be used as terminal for the cluster
How can I specify the spring.profiles.active param with a value from an environment variable using fabric8 maven plugin?

4 Answers

9/13/2018

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.

-- Rico
Source: StackOverflow
3/18/2019

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"}]}'
-- victortv
Source: StackOverflow
9/13/2018

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
-- Nicola Ben
Source: StackOverflow
9/17/2018

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.

-- TinaC
Source: StackOverflow