The admission-policy-engine module enforces security policies and operational restrictions in a Kubernetes cluster. Policies are applied based on Pod Security Standards checks and rules from the following custom resources:

  • OperationPolicy: Describes the operational policy of the cluster.
  • SecurityPolicy: Describes the security policy of the cluster.
  • SecurityPolicyException: Describes exceptions to the cluster security policy.

The deckhouse module processes the OperationPolicy and SecurityPolicy resources. The Deckhouse controller of the deckhouse module uses addon-operator and module hooks to create custom resources for Gatekeeper based on OperationPolicy and SecurityPolicy. Gatekeeper uses the resulting custom resources to validate newly created or updated Kubernetes resources.

For details on the hooks concept, refer to the addon-operator documentation.

For a detailed description of the module, refer to the corresponding documentation section.

Module architecture

The following simplifications are made in the diagram:

  • The diagram shows containers in different pods interacting directly with each other. In reality, they communicate via the corresponding Kubernetes Services (internal load balancers). Service names are omitted if they are obvious from the diagram context. Otherwise, the Service name is shown above the arrow.
  • Pods may run multiple replicas. However, each pod is shown as a single replica in the diagram.

The Level 2 C4 architecture of the admission-policy-engine module and its interaction with other components of Deckhouse Kubernetes Platform (DKP) are shown in the following diagram:

Admission-policy-engine architecture

Module components

The module consists of the following components:

  1. Gatekeeper-controller-manager: A Gatekeeper controller that performs the following operations:

    Security rules are defined using the ConstraintTemplate custom resource and custom resources from the constraints.gatekeeper.sh/* API group. A ConstraintTemplate defines new policy types, based on which specific security policies are created to validate resources.

    It consists of the following containers:

    • manager: Main container.
    • kube-rbac-proxy: Sidecar container providing an RBAC-based authorization proxy for secure access to controller metrics.

  2. Gatekeeper-audit: Implements periodic checks of existing Kubernetes resources for compliance with security policies.

    It consists of the following containers:

    • manager: Main container.
    • constraint-exporter: Sidecar container that exposes additional metrics for the constraints.gatekeeper.sh/* and mutations.gatekeeper.sh/* custom resources.
    • kube-rbac-proxy: Sidecar container providing an RBAC-based authorization proxy for secure access to metrics from manager and constraint-exporter.

  3. Ratify: An optional component consisting of a single ratify container. It provides a Gatekeeper provider implementation for validating metadata of used artifacts. In DKP, this provider is used to verify container image signatures and is available in the SE+, EE, CSE Lite, and CSE Pro editions.

Gatekeeper uses the Provider custom resource to extend resource validation capabilities in Kubernetes. The Provider resource describes the service endpoint to which Gatekeeper sends requests during ValidationWebhook execution. Some DKP modules, such as operator-trivy, can create Provider custom resources and thereby extend the verification capabilities.

Module interactions

The module interacts with the following components:

  • Kube-apiserver:

    • Monitors Kubernetes resources specified in custom resources of the constraints.gatekeeper.sh/* and mutations.gatekeeper.sh/* API groups.
    • Manages ConstraintTemplate, Assign, AssignImage, AssignMetadata, ModifySet, as well as resources from the constraints.gatekeeper.sh/* and config.ratify.deislabs.io/* API groups.

The following external components interact with the module:

  1. Kube-apiserver: Validates Kubernetes resources and checks their compliance with the defined security rules.

  2. Prometheus-main: Collects module metrics.

Additional resources