Thank you for reading this post, don't forget to subscribe!
- Возможность запуска привилегированных контейнеров
- Повышение привилегий
- Доступ к типам томов
- Доступ к файловым системам хоста
- Использование хост-сети
Как создать политику безопасности пода Kubernetes
Давайте создадим политику безопасности пода Kubernetes, которая предотвращает создание привилегированных модулей и контролирует доступ к томам.
Во-первых, мы должны создать файл YAML.
В терминале введите команду:
nano psp.yaml
В этот файл вставьте следующее:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: psp spec: privileged: false seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny volumes: - '*' |
В этом файле мы запрещаем создание привилегированных модулей с помощью строки:
|
1 |
privileged: false |
- SeLinux – позволяет любому пользователю управлять SELinux в модулях.
- Linux groups – дополнительные группы
- runAsUser – позволяет пользователям запускать точки входа в контейнер с другим именем пользователя
- fsGroup – тома, которые поддерживают управление собственностью
Сохраните и закройте файл.
Теперь мы должны применить политику.
|
1 |
kubectl apply -f psp.yaml |
|
1 |
podsecurity.policy/psp created |
В любой момент вы можете изменить файл YAML и выполнить ту же команду, чтобы переконфигурировать политику.
Убедитесь, что ваша политика доступна, введя команду:
|
1 |
kubectl get psp |
Как назначить политику безопасности Kubernetes поду
Теперь, когда вы создали свою политику, возникает законный вопрос как ее назначить?
Это делается с помощью управления доступом на основе ролей (RBAC).
Создайте конфигурацию RBAC для политики с помощью команды:
|
1 |
nano rbac-psp.yaml |
В этот файл вставьте следующее:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: psp:psp rules: - apiGroups: - extensions resources: - podsecuritypolicies resourceNames: - psp verbs: - use --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: psp:psp subjects: - kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: psp:psp apiGroup: rbac.authorization.k8s.io |
Приведенный выше файл создаст роль кластера с именем psp, которая может использовать нашу новую политику, которую мы назвали psp.
Это также создаст привязку роли на уровне кластера, которая предоставляет доступ к роли psp: psp каждому аутентифицированному пользователю.
|
1 |
kubectl apply -f rbac-psp.yaml |
Теперь мы создали политику и контроль RBAC.
Давайте выясним, сможем ли мы теперь использовать эту новую политику.
Введите команду:
|
1 |
kubectl auth can-i use psp/psp |
Выход должен сказать «yes».
Конечно, система должна сказать «yes», так как я пользователь с правами администратора.
Но что, если мы проверим это с другим пользователем?
Сделайте это с помощью команды:
|
1 |
kubectl auth can-i use psp/psp --as-group=system:authenticated --as=any-user |
Теперь вы должны увидеть «no» в ответе.