16

I have set up Kubernetes secrets.

kubectl create secret generic mysecret --from-file=mysecret=/home/ubuntu/secret.txt

And this secret can be converted to plaintext using the same kubectl command:

kubectl get secret mysecret -o yaml
# and base64 decode

How do I limit access to this secret? I only want a certain pods and only me as an operator to have access to this secret.

mohan08p
  • 5,002
  • 1
  • 28
  • 36
enerudfwqenq
  • 301
  • 2
  • 4
  • 8

1 Answers1

11

OK, so you need to define a (cluster) role and then bind it to you (== human user is the target entity) and/or to a service account (== app is the target entity) which you then use in the pod instead of the default one.

The respective secretadmin role (or choose whatever name you prefer) would look something like this (vary verbs as required):

$ kubectl create clusterrole secretadmin \
          --verb=get --verb=list --verb=create --verb=update  \
          --resource=secret \
          --namespace=mysuperproject

Once you've defined the role, you can attach (or: bind) it to a certain entity. Let's go through the case of the service account (similar then for a human user, just simpler). So first we need to create the service account, here called thepowerfulapp which you will then use in your deployment/pod/whatever:

$ kubectl -n mysuperproject create sa thepowerfulapp

And now it's time to tie everything together with the following binding called canadminsecret

$ kubectl create clusterrolebinding canadminsecret \
          --role=secretadmin \
          --serviceaccount=mysuperproject:thepowerfulapp \
          --namespace=mysuperproject
Michael Hausenblas
  • 13,162
  • 4
  • 52
  • 66
  • 3
    Isn't it true that also any user able to create a Pod in the `mysuperproject` namespace will be able to mount the Secret in a container and see it? – giorgiosironi Nov 14 '19 at 16:37
  • 4
    Yes @giorgiosironi this is a known limitation of RBAC in Kubernetes, IOW it would be desirable if it would be more fine-grained, being able to address individual resources rather than on the namespace/kind level. See also this excellent KubeCon talk by Vallery Lancey & Seth McCombs where they discuss said issue: https://www.youtube.com/watch?v=TZ73EBP2a9Q – Michael Hausenblas Nov 14 '19 at 19:25
  • 4
    the `--namespace` flag is unnecessary since you are creating clusterrole/clusterrolebindings, these resources are not bound to a namespace, they create cluster wide access controls. – alewitt Aug 19 '20 at 13:44