tgoop.com/sec_devops/420
Last Update:
The Power of Kubernetes RBAC
В конце того года я писал про опасность глаголов escalate и list при организации RBAC в Kubernetes. Тем не менее я не написал про bind, который имеет точно такой же эффект как и escalate. То есть, если пользователь или SA обладают правами на bind, то абсолютно неважно, какие глаголы еще выставлены у его роли в RBAC, ведь он может запросто изменить свою роль на cluster-admin. Про эффект bind можно прочитать в отдельной статье. Стоит это учитывать при написании RBAC, либо их аудите.
К теме RBAC хочется также упомянуть статью "The Power of Kubernetes RBAC LIST". Проблему с неявными полномочиями также можно встретить в GKE при выставлении прав container.secrets.list. Тут все еще страшнее, так как данные права есть в популярных IAM ролях Kubernetes Engine Developer и Kubernetes Engine Admin. Это в свою очередь позволяет пользователям получить доступ к секретам и завладеть ролью cluster-admin. Авторы в данном случае советуют руководствоваться правилом "один GKE на один проект" и использовать RBAC вместо IAM, чтобы распределять роли команды в рамках неймспейсов, а не назначать права на весь кластер. А еще в статье упоминается утилита, которая поможет выводить перечень конкретных прав для IAM в GCP.
В заключении хочу упомянуть про глагол impersonate. Он позволяет выдать себя за другого пользователя. На текущий момент я не встречал про то, как можно использовать данные права в рамках атаки на кластер, но на сайте CNCF есть статья, как используется impersonate для отладки RBAC.
#k8s #ops #gcp
BY Security Wine (бывший - DevSecOps Wine)
Share with your friend now:
tgoop.com/sec_devops/420