User without access to secrets can create pod, mounting secret

[jerer]

What happened:
I've created Role without access to Kubernetes secrets, but with ability to create pods, exec commands in pods. User with that role can mount any secret in namespace into pod and access it through exec commands in pod, so effectively can read all secrets.

What you expected to happen:
Pod creation (that mount secrets) should fail.

How to reproduce it (as minimally and precisely as possible):

Create secret:

apiVersion: v1
kind: Secret
metadata:
  name: test-secret
data:
  username: bXktYXBw
  password: Mzk1MjgkdmRnN0pi

Create Role, RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-secrets
  namespace: default
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
  - create
  - delete
- apiGroups:
  - ""
  resources:
  - pods/exec
  verbs:
  - create
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-secrets
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: test-secrets
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: u100

Create Pod as u100 user (kubectl --as=u100):

apiVersion: v1
kind: Pod
metadata:
  name: p
  namespace: default
spec:
  containers:
  - command:
    - sleep
    - 10h
    name: p
    image: alpine
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secret-volume
  volumes:
    - name: secret-volume
      secret:
        secretName: test-secret

Verify that u100 user can get secret:

kubectl --as=u100 exec p -- cat /etc/secret-volume/password

Anything else we need to know?:

Environment:

• Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.1", GitCommit:"b7394102d6ef778017f2ca4046abbaa23b88c290", GitTreeState:"clean", BuildDate:"2019-04-08T17:11:31Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"c27b913fddd1a6c480c229191a087698aa92f0b1", GitTreeState:"clean", BuildDate:"2019-02-28T13:30:26Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}

• Cloud provider or hardware configuration:
  Baremetal
• Install tools:
  Kubeadm

[k8s-ci-robot]

@jerer: There are no sig labels on this issue. Please add a sig label by either:

1. mentioning a sig: @kubernetes/sig-<group-name>-<group-suffix>
   e.g., @kubernetes/sig-contributor-experience-<group-suffix> to notify the contributor experience sig, OR

2. specifying the label manually: /sig <group-name>
   e.g., /sig scalability to apply the sig/scalability label

Note: Method 1 will trigger an email to the group. See the group list.
The <group-suffix> in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[liggitt]

Granting a user permission to create pods allows them to run processes that make use of resources in the pod's namespace, including secrets and configmaps.

Allowing them to create pods with arbitrary images, or invoking arbitrary commands, or to exec/attach into those pods can allow the user to access data they could not access directly via the API.

The ACL boundary for the content of pod specs is the namespace level (a pod spec can refer to a service account, secret, or configmap in its namespace)

If you want to add additional policies on top of that, you can do so using webhook admission and external policy rules.

/close

[k8s-ci-robot]

@liggitt: Closing this issue.

In response to this:

Granting a user permission to create pods allows them to run processes that make use of resources in the pod's namespace, including secrets and configmaps.

Allowing them to create pods with arbitrary images, or invoking arbitrary commands, or to exec/attach into those pods can allow the user to access data they could not access directly via the API.

The ACL boundary for the content of pod specs is the namespace level (a pod spec can refer to a service account, secret, or configmap in its namespace)

If you want to add additional policies on top of that, you can do so using webhook admission and external policy rules.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.