Home / server / Questions / 1167831
Accepted
Sagar
Asked: 2024-11-16 00:30:50 +0800 CST

Why can the user "get" secrets, given the following clusterrole/role combination?

  • 772

I have the following ClusterRoles defined:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer-system
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - list
- nonResourceURLs:
  - '*'
  verbs:
  - list

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer-nonsystem
rules:
- apiGroups:
  - '*'
  resources:
  - secrets
  - PersistentVolumes
  - Role
  - RoleBinding
  verbs:
  - list
- apiGroups:
  - '*'
  resources:
  - deployments
  - pods
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
- nonResourceURLs:
  - '*'
  verbs:
  - list

I use the following RoleBindings to assign a user the above ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: theuser-nonsystem-role-binding
  namespace: nonsystem-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: deployer-nonsystem
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: theuser

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: theuser-kube-system-role-binding
  namespace: system-namespace
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: deployer-system
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: theuser

However, they are able to run a kubectl -n [NAMESPACE] get secrets -o yaml and see all the secrets. I would expect this call to be forbidden based on the ClusterRole specifications above.

Am I missing or misunderstanding something here? Why can the user "get" secrets?

UPDATE: Please note: my issues is NOT that they can list secrets. My issue here is that the user can "get" secrets (different verbs!)

kubernetes

1 Answers

  1. Best Answer

    Am I missing or misunderstanding something here? Why can the user "get" secrets?

    Because the list verbs means "get applied to multiple resources". When you perform the kubectl get secret operation without specifying an individual secret, you are performing a list operation.

    Given the RBAC in your question, I can ask for all the secrets in the system-namespace namespace:

    $ kubectl -n system-namespace get secret
NAME      TYPE     DATA   AGE
secret1   Opaque   1      2m54s

    But I cannot ask for a specific secret:

    $ kubectl -n system-namespace get secret secret1
Error from server (Forbidden): secrets "secret1" is forbidden: User "lars" cannot get resource "secrets" in API group "" in the namespace "system-namespace"

    You should think of list as a more powerful version of get, since it permits someone the ability to enumerate and retrieve all the secrets. With only get permission, an entity must know the name of a specific secret in order to access it, and you can in fact restrict get access to specific resources by setting the resourceNames component of a rule.

    Assuming that system-namespace has secrets secret1 and secret2, if I have an account bound to the following role:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployer-system
rules:
- apiGroups:
  - ''
  resourceNames:
  - secret1
  resources:
  - secrets
  verbs:
  - get

    Then I can only retrieve secret secret1:

    $ kubectl get secret secret1
NAME      TYPE     DATA   AGE
secret1   Opaque   1      10m
$ kubectl get secret secret2
Error from server (Forbidden): secrets "secret2" is forbidden: User "lars" cannot get resource "secrets" in API group "" in the namespace "system-namespace"
    • 1