Как думаете, насколько опасна такая Role?

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-exec-view-role
rules:
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["get"]

Если вы думали, что только Role/ClusterRole с правами create – pods/exec может позволить пользователю делать exec в Pod, то вы ошибались. Благодаря особенностям работы Websockets, прав get – pods/exec будет достаточно, чтобы выполнять команды в Pod.

Что ещё более интересно, так это то, что такое поведение уже было давно в Kubernetes, но вы могли его не заметить, поскольку по умолчанию для exec использовался SPDY протокол, а не Websockets. О проблеме известно с 2019 года!

Чтобы получить exec при правах get – pods/exec, например, можно воспользоваться wscat:

wscat -s "base64url.bearer.authorization.k8s.io.$token, base64.channel.k8s.io" -n -c 'wss://192.168.99.100:8443/api/v1/namespaces/default/pods/testpod/exec?container=testpod&command=sh&stdout=true&stderr=true&stdin=true&tty=true'

Однако, начиная с версии Kubernetes 1.31 для операций attach, exec и port-forward теперь по умолчанию используется Websockets, а это значит, что прав get – pods/exec будет достаточно, чтобы выполнять команды в Pod.

Нельзя не упомянуть свежую заметку Rory McCune – When is read-only not read-only?, в которой он рассказал об этой особенности.