25

I have a Service Account which I'd like to grant permissions to read/write/update/delete Secrets within a specific namespace. I'm not clear about how exactly Service Accounts, Roles, Bindings, etc. work together to grant the right permissions.

What kubectl invocations or YAML do I need to do to grant these permissions to the service account?

Here's the YAML for the Service Account I have so far:

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2018-10-09T17:45:20Z
  name: testaccount
  namespace: test
  resourceVersion: "369702913"
  selfLink: /api/v1/namespaces/test/serviceaccounts/testaccount
  uid: f742ed5c-c1b3-11e8-8a69-0ade4132ab56
secrets:
- name: testaccount-token-brjxq
Rico
  • 58,485
  • 12
  • 111
  • 141
user108471
  • 2,488
  • 3
  • 28
  • 41

2 Answers2

29

You need to create Role and Role binding.

Create a role:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 namespace: test
 name: role-test-account
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Create a role binding:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: role-test-account-binding
 namespace: test
subjects:
- kind: ServiceAccount
  name: test-account
  namespace: test
roleRef:
 kind: Role
 name: role-test-account
 apiGroup: rbac.authorization.k8s.io

You can read more about using RBAC Authorization

Atul Verma
  • 2,012
  • 15
  • 8
6

So you have your SA testaccount. Let's assume your app (the one that manipulates the secrets) has a container image myorg/myapp:01. You'd launch it then as follows:

$ kubectl -n test run myapp \
    --image=myorg/myapp:01 \
    --serviceaccount=testaccount

But what about the permissions? Well, doesn't really matter if you do this before or after the app has launched, but at some point in time, do:

$ kubectl create clusterrole secretmanipulator \
    --verb=get --verb=list --verb=watch \
    --verb=create --verb=update --verb=patch --verb=delete \
    --resource=secrets 

$ kubectl -n test create rolebinding allowsecretmanipulation \
    --clusterrole=secretmanipulator \
    --serviceaccount=test:testaccount

Note that I created a cluster role above and used a role binding then to attach it to your SA. Why? It's more reusable like that. Of course a simple role would also work here but then you'd need to re-create it for every namespace.

Michael Hausenblas
  • 13,162
  • 4
  • 52
  • 66
  • I accepted the earlier answer with the YAML solution, but I appreciate this alternative take using a cluster role and kubectl invocations. – user108471 Oct 11 '18 at 14:11
  • 2
    Yup and just to be clear, the other answer, while not incorrect is not complete as it doesn't address the important step to actually use the SA in the pod ;) – Michael Hausenblas Oct 11 '18 at 14:15
  • I would argue that a tighter and more restrictive authz configuration is generally securer. Use cluster roles ONLY WHEN you know for sure that your service account must be granted permissions cross namespaces - otherwise it's not a good RBAC policy. – Devy Feb 12 '19 at 15:55