New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Admission controller to attach additional secrets to a service account #9902

Closed
erictune opened this Issue Jun 16, 2015 · 7 comments

Comments

Projects
None yet
6 participants
@erictune
Copy link
Member

erictune commented Jun 16, 2015

The following does not work but I would like it to:

# Make secret
$ kubectl create -f - <<EOF
apiVersion: v1
data:
  thing: dGVzdAo=
kind: Secret 
metadata:
  name: test-secret
type: Opaque
EOF
secrets/test-secret
# Make non-default service account
$ kubectl create -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-sa
EOF
serviceaccounts/test-sa
# Verify creation and get the existing token name
$ kubectl get serviceaccounts/test-sa -oyaml 
apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2015-06-16T21:52:39Z
  name: test-sa
  namespace: default
  resourceVersion: "313260"
  selfLink: /api/v1/namespaces/default/serviceaccounts/test-sa
  uid: 02348e46-1572-12e5-afc2-41010ae0021f
secrets:
- name: test-sa-token-wr9j3
#  Update service account to have another secret
$ kubectl update -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test-sa
secrets:
- name: test-sa-token-wr9j3
- name: test-secret
EOF
serviceaccounts/test-sa
# Create a pod that uses test-sa and both its secrets 
$ kubectl create -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: p1
spec:
  containers:
  - image: progrium/busybox
    name: c
    command: [ "ls", "-lR", "/var/run/secrets/"]
  serviceAccount: test-sa
  restartPolicy: Never
EOF
# Sadly, only one secret got mounted.
$kubectl get pods/p1 -oyaml | grep volumes -A 3
  volumes:
  - name: test-sa-token-wr9j3
    secret:
      secretName: test-sa-token-wr9j3

@liggitt is there a way to talk the service account controller into mounting the second secret?

@liggitt

This comment has been minimized.

Copy link
Member

liggitt commented Jun 16, 2015

No… there's no place to indicate default mount points or intent to auto mount. I think @pmorie had one or more issues open about that specifically related to secrets, aside from service accounts, but not much happened with them yet

@erictune

This comment has been minimized.

Copy link
Member Author

erictune commented Jun 16, 2015

Do you and pmorie agree this is something that we'd want to do in kubernetes, aside from the issue of agreeing on default mount points for ad-hoc secrets?

@erictune erictune added this to the v1.0-post milestone Jun 16, 2015

@bgrant0607 bgrant0607 removed this from the v1.0-post milestone Jul 24, 2015

@ibotty

This comment has been minimized.

Copy link

ibotty commented Jul 30, 2016

Regarding the mount point: What about using an annotation in the secret and if none is given, mounting below /run/secrets/kubernetes.io/secrets/<name>?

@ibotty

This comment has been minimized.

Copy link

ibotty commented Jul 30, 2016

Oh, and that should definitely be opt-in per container in the pod: Privilege separation within a pod!

@erictune

This comment has been minimized.

Copy link
Member Author

erictune commented Aug 1, 2016

If it is opt in per container, then there is nothing left to do here!

@liggitt

This comment has been minimized.

Copy link
Member

liggitt commented Mar 30, 2017

automountServiceAccountToken option was added to service account and to pod spec

PodPresets allow automounting additional secrets/configmaps

@erictune

This comment has been minimized.

Copy link
Member Author

erictune commented Jun 16, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment