Compare languages | Модуль admission-policy-engine: FAQ

Как настроить альтернативные решения по управлению политиками безопасности?

How do I configure alternative security policy management solutions?

Для корректной работы DKP необходимы расширенные привилегии на запуск и работу полезной нагрузки системных компонентов. Если вместо модуля admission-policy-engine используется альтернативное решение по управлению политиками безопасности (например, Kyverno), необходима настройка исключений для следующих пространств имен:

  • kube-system;
  • все пространства имен с префиксом d8-* (например, d8-system).

For DKP to work correctly, extended privileges are required to run and operate system component payloads. If you are using some alternative security policy management solution (e. g., Kyverno) instead of the admission-policy-engine module, you have to configure exceptions for the following namespaces:

  • kube-system;
  • all namespaces with the d8-* prefix (e.g., d8-system).

Как расширить политики Pod Security Standards?

How do I extend Pod Security Standards policies?

Pod Security Standards реагируют на label security.deckhouse.io/pod-policy: restricted или security.deckhouse.io/pod-policy: baseline.

Pod Security Standards respond to the security.deckhouse.io/pod-policy: restricted or security.deckhouse.io/pod-policy: baseline label.

Чтобы расширить политику Pod Security Standards, добавив к существующим проверкам политики свои собственные, необходимо:

  • создать шаблон проверки (ресурс ConstraintTemplate);
  • привязать его к политике restricted или baseline.

To extend the Pod Security Standards policy by adding your checks to existing checks, you need to:

  • Create a constraint template for the check (a ConstraintTemplate resource).
  • Bind it to the restricted or baseline policy.

Пример шаблона для проверки адреса репозитория образа контейнера:

Example of the ConstraintTemplate for checking a repository URL of a container image:

yaml apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8sallowedrepos spec: crd: spec: names: kind: K8sAllowedRepos validation: openAPIV3Schema: type: object properties: repos: type: array items: type: string targets:

  • target: admission.k8s.gatekeeper.sh rego: | package d8.pod_security_standards.extended

yaml apiVersion: templates.gatekeeper.sh/v1 kind: ConstraintTemplate metadata: name: k8sallowedrepos spec: crd: spec: names: kind: K8sAllowedRepos validation: openAPIV3Schema: type: object properties: repos: type: array items: type: string targets:

  • target: admission.k8s.gatekeeper.sh rego: | package d8.pod_security_standards.extended

violation[{“msg”: msg}] { container := input.review.object.spec.containers[] satisfied := [good | repo = input.parameters.repos[] ; good = startswith(container.image, repo)] not any(satisfied) msg := sprintf(“container <%v> has an invalid image repo <%v>, allowed repos are %v”, [container.name, container.image, input.parameters.repos]) }

violation[{“msg”: msg}] { container := input.review.object.spec.containers[] satisfied := [good | repo = input.parameters.repos[] ; good = startswith(container.image, repo)] not any(satisfied) msg := sprintf(“container <%v> has an invalid image repo <%v>, allowed repos are %v”, [container.name, container.image, input.parameters.repos]) }

violation[{“msg”: msg}] { container := input.review.object.spec.initContainers[] satisfied := [good | repo = input.parameters.repos[] ; good = startswith(container.image, repo)] not any(satisfied) msg := sprintf(“container <%v> has an invalid image repo <%v>, allowed repos are %v”, [container.name, container.image, input.parameters.repos]) }

violation[{“msg”: msg}] { container := input.review.object.spec.initContainers[] satisfied := [good | repo = input.parameters.repos[] ; good = startswith(container.image, repo)] not any(satisfied) msg := sprintf(“container <%v> has an invalid image repo <%v>, allowed repos are %v”, [container.name, container.image, input.parameters.repos]) }

Пример привязки проверки к политике restricted:

Example of binding a check to the restricted policy:

yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sAllowedRepos metadata: name: prod-repo spec: match: kinds:

  • apiGroups: [””] kinds: [“Pod”] namespaceSelector: matchLabels: security.deckhouse.io/pod-policy: restricted parameters: repos:
  • “mycompany.registry.com”

yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sAllowedRepos metadata: name: prod-repo spec: match: kinds:

  • apiGroups: [””] kinds: [“Pod”] namespaceSelector: matchLabels: security.deckhouse.io/pod-policy: restricted parameters: repos:
  • “mycompany.registry.com”

Пример демонстрирует настройку проверки адреса репозитория в поле image у всех подов, создающихся в пространстве имен, имеющих label security.deckhouse.io/pod-policy: restricted. Если адрес в поле image создаваемого пода начинается не с mycompany.registry.com, под создан не будет.

The example demonstrates the configuration of checking the repository address in the image field for all Pods created in the namespace having the security.deckhouse.io/pod-policy : restricted label. A Pod will not be created if the address in the image field of the Pod does not start with mycompany.registry.com.

Подробнее о шаблонах и языке политик можно узнать в документации Gatekeeper.

The Gatekeeper documentation may find more info about templates and policy language.

Больше примеров описания проверок для расширения политики можно найти в библиотеке Gatekeeper.

Find more examples of checks for policy extension in the Gatekeeper Library.

Что, если несколько политик (операционных или безопасности) применяются на один объект?

What if there are multiple policies (operational or security) that are applied to the same object?

В таком случае необходимо, чтобы конфигурация объекта соответствовала всем политикам, которые на него распространяются.

In that case the object’s specification have to fulfil all the requirements imposed by the policies.

Например, рассмотрим две следующие политики безопасности:

For example, consider the following two security policies:

yaml apiVersion: deckhouse.io/v1alpha1 kind: SecurityPolicy metadata: name: foo spec: enforcementAction: Deny match: namespaceSelector: labelSelector: matchLabels: name: test policies: readOnlyRootFilesystem: true requiredDropCapabilities:

  • MKNOD

    apiVersion: deckhouse.io/v1alpha1 kind: SecurityPolicy metadata: name: bar spec: enforcementAction: Deny match: namespaceSelector: labelSelector: matchLabels: name: test policies: requiredDropCapabilities:

  • NET_BIND_SERVICE

yaml apiVersion: deckhouse.io/v1alpha1 kind: SecurityPolicy metadata: name: foo spec: enforcementAction: Deny match: namespaceSelector: labelSelector: matchLabels: name: test policies: readOnlyRootFilesystem: true requiredDropCapabilities:

  • MKNOD

    apiVersion: deckhouse.io/v1alpha1 kind: SecurityPolicy metadata: name: bar spec: enforcementAction: Deny match: namespaceSelector: labelSelector: matchLabels: name: test policies: requiredDropCapabilities:

  • NET_BIND_SERVICE

Тогда для выполнения требований приведенных политик безопасности в спецификации контейнера нужно указать:

Then, in order to fulfill the requirements of the above security policies, the following settings must be set in a container specification:

yaml securityContext: capabilities: drop:

  • MKNOD
  • NET_BIND_SERVICE readOnlyRootFilesystem: true

yaml securityContext: capabilities: drop:

  • MKNOD
  • NET_BIND_SERVICE readOnlyRootFilesystem: true

Проверка подписи образов

Verification of image signatures

Доступно только в Enterprise edition.

This feature is available in Enterprise Edition only.

В модуле реализована функция проверки подписи образов контейнеров, подписанных с помощью инструмента Cosign. Проверка подписи образов контейнеров позволяет убедиться в их целостности (что образ не был изменен после его создания) и подлинности (что образ был создан доверенным источником). Включить проверку подписи образов контейнеров в кластере можно с помощью параметра policies.verifyImageSignatures ресурса SecurityPolicy.

The module implements a function for checking the signatures of container images signed using Cosign. Checking the signatures of container images allows you to ensure their integrity (that the image has not been modified since its creation) and authenticity (that the image was created by a trusted source). You can enable container image signature verification in the cluster using the policies.verifyImageSignatures parameter of the SecurityPolicy resource.

Шаги для подписания образа:

  • Сгенерируйте ключи: cosign generate-key-pair
  • Подпишите образ: cosign sign --key <key> <image>

Steps to sign an image:

  • Generate keys: cosign generate-key-pair
  • Sign the image: cosign sign --key <key> <image>

Подробнее о работе с Cosign можно узнать в документации.

For more information on working with Cosign, you can check the documentation.

Пример SecurityPolicy для настройки проверки подписи образов контейнеров:

Example of SecurityPolicy for configuring the signature verification of container images:

yaml apiVersion: deckhouse.io/v1alpha1 kind: SecurityPolicy metadata: name: verify-image-signatures spec: match: namespaceSelector: labelSelector: matchLabels: kubernetes.io/metadata.name: default policies: verifyImageSignatures:

  • reference: docker.io/myrepo/* publicKeys:
  • |- —–BEGIN PUBLIC KEY—– MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8nXRh950IZbRj8Ra/N9sbqOPZrfM 5/KAQN0/KjHcorm/J5yctVd7iEcnessRQjU917hmKO6JWVGHpDguIyakZA== —–END PUBLIC KEY—–
  • reference: company.registry.com/* dockerCfg: zxc== publicKeys:
  • |- —–BEGIN PUBLIC KEY—– MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8nXRh950IZbRj8Ra/N9sbqOPZrfM 5/KAQN0/KjHcorm/J5yctVd7iEcnessRQjU917hmKO6JWVGHpDguIyakZA== —–END PUBLIC KEY—–

yaml apiVersion: deckhouse.io/v1alpha1 kind: SecurityPolicy metadata: name: verify-image-signatures spec: match: namespaceSelector: labelSelector: matchLabels: kubernetes.io/metadata.name: default policies: verifyImageSignatures:

  • reference: docker.io/myrepo/* publicKeys:
  • |- —–BEGIN PUBLIC KEY—– MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8nXRh950IZbRj8Ra/N9sbqOPZrfM 5/KAQN0/KjHcorm/J5yctVd7iEcnessRQjU917hmKO6JWVGHpDguIyakZA== —–END PUBLIC KEY—–
  • reference: company.registry.com/* dockerCfg: zxc== publicKeys:
  • |- —–BEGIN PUBLIC KEY—– MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8nXRh950IZbRj8Ra/N9sbqOPZrfM 5/KAQN0/KjHcorm/J5yctVd7iEcnessRQjU917hmKO6JWVGHpDguIyakZA== —–END PUBLIC KEY—–

Политика не влияет на создание подов, адреса образов контейнеров которых не подходят под описанные в параметре reference. Если же адрес какого-либо образа контейнера подходит под описанные в параметре reference политики, и образ не подписан или подпись не соответствует указанным в политике ключам, создание пода будет запрещено.

Policies do not affect the creation of pods whose container image addresses do not match those described in the reference parameter. If the address of any Pod container image matches those described in the reference policies, and the image is not signed or the signature does not correspond to the keys specified in the policy, the creation of the pod will be prohibited.

Пример вывода ошибки при создании пода с образом контейнера, не прошедшим проверку подписи:

Example of an error output when creating a Pod with a container image that has not passed the signature verification:

console [verify-image-signatures] Image signature verification failed: nginx:1.17.2

console [verify-image-signatures] Image signature verification failed: nginx:1.17.2