Как думаете, насколько опасна такая
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?, в которой он рассказал об этой особенности.
