Rules

• 1: Mutate
• 1.1: Workloads
• 2: Enforce
• 2.1: Workloads
• 2.2: Metadata
• 2.3: Network
• 2.4: Storage

spec:
  rules:
    - audience:
        - kind: Group
          name: system:authenticated
      enforce:
        action: allow
        metadata:
          - kinds:
              - ConfigMap
            annotations:
              example.corp/cost-center:
                required: true
                values:
                  - exp: "^INV-[0-9]{4}$"

spec:
  rules:
    - audience:
        # Match one exact Kubernetes username.
        - kind: User
          name: alice@example.com

        # Match any request carrying this group.
        - kind: Group
          name: oidc:engineering

        # Match one Kubernetes service account.
        - kind: ServiceAccount
          name: system:serviceaccount:delivery:deployer
      enforce:
        action: deny
        metadata:
          - apiGroups:
              - v1
            kinds:
              - Namespace
            labels:
              pod-security.kubernetes.io/enforce:
                managed: restricted

system:serviceaccount:<namespace>:<service-account-name>

spec:
  rules:
    - audience:
        - kind: Custom
          name: CapsuleUser
        - kind: Custom
          name: Administrator
        - kind: Custom
          name: TenantOwner
        - kind: Custom
          name: Controller
        - kind: Group
          name: system:masters
      enforce:
        action: allow
        metadata:
          - apiGroups:
              - v1
            kinds:
              - Namespace
            annotations:
              example.corp/cost-center:
                default: II-1

spec:
  rules:
    - audience:
        - kind: Custom
          name: TenantOwner
      enforce:
        action: allow
        metadata:
          - kinds:
              - ConfigMap
            labels:
              owner-managed:
                default: "true"

spec:
  rules:
    - audience:
        - kind: Custom
          name: Controller
      enforce:
        action: allow
        metadata:
          - kinds:
              - Secret
            labels:
              capsule.clastix.io/reconciled:
                managed: "true"

exact:
  - value-a
  - value-b
exp: "value-[0-9]+"

exact:
  - registry.local/team-a/app:1.0.0
  - registry.local/team-b/app:1.0.0
exp: "registry.local/shared/.*"

exact:
  - registry.local/blocked/app:1.0.0
exp: "registry.local/deprecated/.*"
negate: true

mutate:
  - action: merge
    conditions:
      - name: missing-os-selector
        expression: >-
          !has(object.spec.nodeSelector) || !('kubernetes.io/os' in object.spec.nodeSelector)          
    workloads:
      placement:
        nodeSelector:
          kubernetes.io/os: linux

rules:
  - enforce:
      action: deny
      conditions:
        - name: restricted-pods
          expression: |
            has(object.metadata.labels) &&
            'example.com/restricted' in object.metadata.labels &&
            object.metadata.labels['example.com/restricted'] == 'true'            
      workloads:
        placement:
          nodeSelector:
            - key: {exact: [infrastructure.example.com/pool]}
              values: {exact: [dedicated]}
  - enforce:
      action: deny
      conditions:
        - name: external-traffic
          expression: object.spec.type == 'NodePort'
      services:
        types: [NodePort]

rules[0].mutate[1]: conditions[0] ("shared-pool"): ...

enforce: enforcement rule[0]: conditions[0] ("restricted-pods"): ...

1 - Mutate

Use spec.rules[].mutate to set resource properties during admission. It is an ordered list of entries, each with an optional action and a typed resource block. Currently, workloads applies to Pods on creation; security.readOnlyRootFilesystem and registries.imagePullPolicy also apply to newly added ephemeral containers. Mutation targets select compatible Pod locations, with pod including all container groups.

mutate and enforce are sibling keys. Mutation changes the resource; enforcement validates the result. Either can be used alone, and mutated values remain subject to applicable enforcement policies.

See Order and scope for the admission sequence and Conditions for conditional mutations.

Action

Each mutate entry supports an action field:

The action applies to every property in that entry. Use separate entries when properties need different actions:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - mutate:
        - action: merge
          workloads:
            placement:
              nodeSelector:
                kubernetes.io/os: linux
        - action: replace
          workloads:
            placement:
              tolerations:
                - key: infrastructure.example.com/dedicated
                  operator: Equal
                  value: shared
                  effect: NoSchedule

This retains other node-selector keys, but replaces the entire tolerations list. Other admission controllers can subsequently add tolerations.

Replacement happens at the supplied property’s boundary. For example, placement.nodeSelector is replaced as one map and placement.affinity as one object, including all its branches. The placement reference explains which list entries match during a merge and how required affinity is combined. Scalar settings such as security.hostUsers, security.readOnlyRootFilesystem, and registries.imagePullPolicy overwrite selected values with either action.

Omitted and empty values

For example, this clears node selectors and affinity while retaining tolerations and topology-spread constraints:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - mutate:
        - action: replace
          workloads:
            placement:
              nodeSelector: {}
              affinity: {}

1.1 - Workloads

Workload mutations set Pod properties under spec.rules[].mutate[].workloads using native Kubernetes Pod syntax. Use placement settings to select schedulers, assign node pools, add tolerations, spread workloads across topology domains, and configure affinity. Use security settings to configure Pod user namespaces, seccomp/AppArmor profiles, and read-only container root filesystems. Use registry settings to configure container image pull policies and Pod image pull secret references. Placement enforcement validates the resulting placement settings using matchers.

This page covers configuration and mutation behavior. The Reference provides a complete Tenant combining all workload mutation properties with placement, security-profile, and image pull policy enforcement.

Configure workload mutations

Each mutation entry has an optional action and a workloads block containing at least one property to set. Scheduling fields live under workloads.placement; security fields live under workloads.security. targets stays directly under workloads and applies to all configured groups. The action applies to each supplied field inside a group: replacing placement.scheduler preserves an omitted placement.nodeSelector and all omitted security fields. Empty placement: {} or security: {} groups supply no mutations; use an explicit empty map or list on a supported field to clear it. For conditional mutations, see Conditions.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          environment: production
      mutate:
        - action: merge
          workloads:
            placement:
              nodeSelector:
                kubernetes.io/os: linux
      enforce:
        action: allow
        workloads:
          placement:
            nodeSelector:
              - key:
                  exact: [kubernetes.io/os]
                values:
                  exact: [linux]

In selected namespaces, this rule sets the Linux node selector. The allow rule then rejects any additional node-selector entries. mutate and enforce are sibling keys and can be used independently. enforce.action does not select or disable mutations.

Workload mutations apply on Pod creation. security.readOnlyRootFilesystem and registries.imagePullPolicy also apply to newly added ephemeral containers. See Order and scope for the mutate-then-enforce sequence, rule selection, and supported operations.

Targets

Set mutate[].workloads.targets to select where the entry applies. Omitting targets, using targets: [], or selecting pod includes all compatible locations. For mutation, pod includes every regular, init, and ephemeral container. Native sidecars belong to the init-container group.

The table lists supported mutation targets. ✅ indicates mutation support; ❌ means that property cannot be mutated through that target. Controller and volume targets are supported by enforcement but are rejected by the mutation API.

Placement includes placement.scheduler, placement.nodeSelector, placement.tolerations, placement.topologySpreadConstraints, and placement.affinity. These properties, security.hostUsers, security.seccompProfile, security.appArmorProfile, and registries.imagePullSecrets require pod or omitted/empty targets. Seccomp and AppArmor mutation preserves explicit container profiles with both merge and replace; container-specific profile mutation is not supported.

security.readOnlyRootFilesystem and registries.imagePullPolicy support container-specific mutation targets. Use separate mutation entries to combine Pod-level settings with a narrower container selection. Controller and volume targets are not supported for typed workload mutations.

Targets combine by inclusion: listing pod alongside a narrower target still selects all groups. A targets-only mutation is invalid because it has no property to set. Enforcement targets are configured independently and have property-specific matching semantics.

Regular and init containers are mutated on Pod creation. Ephemeral containers are mutated only when newly added through UPDATE pods/ephemeralcontainers. An existing ephemeral container is left unchanged, even if the rule changed since it was added. Other Pod updates, deletes, and subresources do not apply these mutations. On an ephemeral update, the entry’s conditions see the full current Pod, including earlier mutations, but only the new ephemeral containers' securityContext.readOnlyRootFilesystem and imagePullPolicy values can change.

Placement

Scheduler

placement.scheduler sets the Pod’s spec.schedulerName. Use the name of a scheduler configured in your cluster; Capsule selects the scheduler but does not deploy it. See Kubernetes multiple schedulers.

To select a scheduler for every new Pod covered by the rule, use replace:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - mutate:
        - action: replace
          workloads:
            placement:
              scheduler: tenant-scheduler

Omitting placement.scheduler or setting it to null leaves the current value unchanged. An empty or blank configured name is invalid. To select the built-in scheduler, set scheduler: default-scheduler explicitly.

Default a scheduler with a condition

Kubernetes fills an omitted or empty spec.schedulerName with default-scheduler before Capsule receives the admission request. To use a tenant scheduler as the default while preserving custom scheduler names, combine replace with a mutation condition:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - mutate:
        - action: replace
          conditions:
            - name: default-scheduler
              expression: >-
                !has(object.spec.schedulerName) || object.spec.schedulerName in ['', 'default-scheduler']                
          workloads:
            placement:
              scheduler: tenant-scheduler

The condition cannot distinguish an omitted value from an explicitly selected default-scheduler: both reach admission with the built-in name. This rule deliberately replaces both. A custom scheduler supplied by the user or an earlier mutation makes the condition false and is retained.

Keep this scheduler default in its own mutation entry. Conditions gate every property in an entry, so adding node selectors or tolerations to it would make those changes depend on the scheduler condition too. Namespace selection and audience still determine which rules apply. Only new Pods are changed; existing Pods and controller templates retain their settings.

The final scheduler name remains subject to scheduler enforcement. Allow the configured default in any applicable scheduler allow-list, or admission will reject the mutated Pod.

Node selectors

placement.nodeSelector is a map of node-label keys and values. Every entry must match a node for the Pod to be scheduled there.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - mutate:
        - action: merge
          workloads:
            placement:
              nodeSelector:
                infrastructure.example.com/pool: shared

For a Pod whose selector is {infrastructure.example.com/pool: private, disk: ssd}, the example produces:

Later mutations can overwrite the same key. For defaults, see set a value only when it is missing. Use node-selector enforcement to restrict which keys and values remain on the admitted Pod.

Tolerations

placement.tolerations is a list of native Pod tolerations. A toleration permits scheduling onto a node with a matching taint; it does not require that node. Use a node selector or required node affinity to restrict placement to a node pool.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - mutate:
        - action: merge
          workloads:
            placement:
              tolerations:
                - key: infrastructure.example.com/dedicated
                  operator: Equal
                  value: shared
                  effect: NoExecute
                  tolerationSeconds: 60

The duration is not part of the merge identity. A matching toleration receives the supplied tolerationSeconds. Omitting the duration removes an existing limit and makes the toleration unlimited.

Changing a key, operator, value, or effect adds another toleration under merge. Use replace when only the supplied list should remain. Other admission controllers may subsequently inject additional tolerations. All final entries are subject to toleration enforcement, including Kubernetes-injected entries.

Topology spread constraints

placement.topologySpreadConstraints is a list of native Pod spread constraints. Each constraint specifies a topology domain and the Pods to count when spreading.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - mutate:
        - action: merge
          workloads:
            placement:
              topologySpreadConstraints:
                - topologyKey: kubernetes.io/hostname
                  whenUnsatisfiable: ScheduleAnyway
                  maxSkew: 1
                  labelSelector:
                    matchLabels:
                      app: checkout

This expresses a preference to spread Pods labeled app: checkout across hosts. Use DoNotSchedule when the spread constraint must prevent scheduling that would violate it.

If the Pod already has a kubernetes.io/hostname / ScheduleAnyway constraint with maxSkew: 3, the example replaces it with maxSkew: 1 and the supplied selector. Old selector fields and optional fields are not carried forward. An existing topology.kubernetes.io/zone / DoNotSchedule constraint remains with merge and is removed with replace unless it is also supplied.

Changing whenUnsatisfiable creates a different merge identity, even if the topology key is unchanged. For allowed topology keys, skew ranges, and selector operators, see spread enforcement.

Affinity

placement.affinity uses the native Pod structure with three branches: nodeAffinity, podAffinity, and podAntiAffinity. Each can contain required and preferred terms.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - mutate:
        - action: merge
          workloads:
            placement:
              affinity:
                nodeAffinity:
                  requiredDuringSchedulingIgnoredDuringExecution:
                    nodeSelectorTerms:
                      - matchExpressions:
                          - key: topology.kubernetes.io/zone
                            operator: In
                            values: [zone-a, zone-b]
                podAffinity:
                  preferredDuringSchedulingIgnoredDuringExecution:
                    - weight: 50
                      podAffinityTerm:
                        topologyKey: kubernetes.io/hostname
                        labelSelector:
                          matchLabels:
                            app: cache
                podAntiAffinity:
                  preferredDuringSchedulingIgnoredDuringExecution:
                    - weight: 100
                      podAffinityTerm:
                        topologyKey: kubernetes.io/hostname
                        labelSelector:
                          matchLabels:
                            app: checkout

This requires a node in zone-a or zone-b, prefers a host with cache Pods, and prefers to separate checkout Pods across hosts. The referenced node labels must exist on the intended nodes. Omitting namespace selection in these Pod-affinity terms limits their Pod matching to the incoming Pod’s namespace.

Merge

For example, existing node alternatives (disk=ssd OR arch=arm64) combined with supplied zone=a become (disk=ssd AND zone=a) OR (arch=arm64 AND zone=a). Required restrictions accumulate across applicable mutations. Capsule rejects combinations that would produce more than 256 node-selector alternatives. An empty node-selector term matches no nodes.

Preferred-term identity includes the complete node preference or Pod-affinity term, excluding its weight. Requirement and selector-value order are normalized for matching. Supplying the same term with weight 80 updates an existing weight 50; changing the selector adds a distinct preferred term.

Replace

replace replaces all of placement.affinity, including branches omitted from the mutation. Supplying only nodeAffinity also removes existing podAffinity and podAntiAffinity. Use affinity: {} to clear all three branches.

For allowed types, required/preferred modes, selector requirements, and namespace scope, see affinity enforcement. Its matcher syntax uses one flat list across all three affinity types.

Security

Seccomp and AppArmor mutations set only the Pod-level profile on creation. Use targets: [pod] or omit mutation targets for these Pod-level properties. enforce.workloads.targets selects enforcement locations independently. Both merge and replace preserve explicit regular, init, and ephemeral container profiles. Containers without an override inherit the Pod default. See the Pod targets table and profile target example for how enforcement checks those defaults and overrides.

Read-only root filesystem

security.readOnlyRootFilesystem sets the Boolean on every selected container’s securityContext. Like security.hostUsers, both merge and replace set the supplied value, including an explicit false. Omitted or null leaves the value unchanged. Later matching entries can overwrite earlier values; all other container security-context fields are preserved.

This full Tenant makes all container root filesystems read-only in namespaces labeled filesystem-profile: readonly. Namespaces labeled filesystem-profile: init-only apply the setting only to init containers, including native sidecars. Other namespaces keep their submitted values.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          filesystem-profile: readonly
      mutate:
        - action: merge
          workloads:
            targets: [pod]
            security:
              readOnlyRootFilesystem: true
    - namespaceSelector:
        matchLabels:
          filesystem-profile: init-only
      mutate:
        - action: replace
          workloads:
            targets: [pod/initcontainers]
            security:
              readOnlyRootFilesystem: true

In the first profile, pod also selects new ephemeral containers. Choose pod/containers for regular containers only or pod/ephemeralcontainers for new debug containers only. Neither the rule nor a namespace-label change rewrites existing containers. Pods declaring spec.os.name: windows are skipped.

A read-only root filesystem does not make mounted volumes read-only. Applications that write to paths such as /tmp need suitable writable volume mounts. See the Kubernetes security-context documentation. This field is a mutation setting; there is no corresponding enforce.workloads.security.readOnlyRootFilesystem matcher.

Host user namespace

security.hostUsers selects whether the Pod uses the host user namespace.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - mutate:
        - action: merge
          workloads:
            security:
              hostUsers: false

Both actions overwrite an existing Boolean. A later entry can change false to true or the reverse. This property is independent of a container’s runAsUser and has no corresponding enforce.workloads.security.hostUsers matcher.

The Kubernetes version, operating system, and container runtime must support the requested setting. Kubernetes validates incompatible Pod settings; Capsule does not adjust other security or host-namespace fields. See Kubernetes user namespaces.

Seccomp

security.seccompProfile sets spec.securityContext.seccompProfile on new Linux Pods. Containers inherit this Pod default unless their own security context supplies a seccomp profile. This includes regular, init, and ephemeral containers.

Seccomp mutation behavior

Merge treats the profile as one property: it does not fill a missing localhostProfile inside an already supplied profile. A Localhost profile must include its path. Replacing Localhost with RuntimeDefault removes the old path.

Other security-context fields and explicit container profiles are preserved. Use seccomp enforcement to prevent container overrides from bypassing the intended profile. Mutations use the existing conditions and order, run only on Pod creation, and skip Pods declaring spec.os.name: windows. They do not change running Pods or controller templates.

Default to RuntimeDefault

This complete Tenant defaults seccomp in namespaces labeled security-profile: confined. The allow rule requires every container’s effective profile to be RuntimeDefault, including containers added later through pods/ephemeralcontainers.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          security-profile: confined
      mutate:
        - action: merge
          workloads:
            security:
              seccompProfile:
                type: RuntimeDefault
      enforce:
        action: allow
        workloads:
          security:
            seccompProfiles:
              - types: [RuntimeDefault]

An explicit container-level Unconfined profile remains unchanged by mutation and is rejected by enforcement. Namespaces without the selector label do not receive either rule effect.

Set a local seccomp path

Set type: Localhost together with localhostProfile. The path is relative to the kubelet’s seccomp directory and must not be absolute or contain .. path segments. For example, profiles/solar.json refers to /var/lib/kubelet/seccomp/profiles/solar.json when the kubelet uses its default root directory. It is a file on the node, independent of the container’s filesystem. See the Kubernetes seccomp tutorial.

This Tenant replaces the Pod default with that local profile and allows only that profile for the effective container checks:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          security-profile: local-seccomp
      mutate:
        - action: replace
          workloads:
            security:
              seccompProfile:
                type: Localhost
                localhostProfile: profiles/solar.json
      enforce:
        action: allow
        workloads:
          security:
            seccompProfiles:
              - types: [Localhost]
                localhostProfiles:
                  - exact: [profiles/solar.json]

Use action: merge instead to supply this profile only when the Pod profile is absent. With the allow-list above, an existing different profile is then preserved by merge and rejected by enforcement.

Install the file on every eligible node before using the rule, or combine the rule with placement that selects prepared nodes. Capsule writes the profile reference; it does not distribute or inspect the file. A Pod can pass admission and still fail to start if the profile is unavailable on its node.

AppArmor

security.appArmorProfile sets spec.securityContext.appArmorProfile on new Linux Pods. The Pod value supplies the default for containers that have no AppArmor override. Use this mutation only for workloads placed on nodes with AppArmor support. Explicit RuntimeDefault can prevent a Pod from starting on a node without that support. See the AppArmor prerequisites.

AppArmor mutation behavior

Merge does not complete a partially supplied Localhost profile. Replacing a Localhost profile with RuntimeDefault removes the old localhostProfile. Other security-context fields and container overrides, including legacy AppArmor annotations, remain unchanged. Pair mutation with AppArmor enforcement to validate these effective container choices.

The existing conditions and order apply. Mutations run only on Pod creation and skip Pods declaring spec.os.name: windows; they do not change running Pods or controller templates.

Default the AppArmor profile

This Tenant supplies RuntimeDefault and requires it for every effective container profile in the selected namespaces:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          security-profile: apparmor
      mutate:
        - action: merge
          workloads:
            security:
              appArmorProfile:
                type: RuntimeDefault
      enforce:
        action: allow
        workloads:
          security:
            appArmorProfiles:
              - types: [RuntimeDefault]

Set a local AppArmor profile

For AppArmor, localhostProfile is the loaded profile name, such as solar-confined. It is not a filesystem path to the profile definition. The name must match the profile loaded on the node. See Specifying AppArmor confinement.

This Tenant replaces the Pod default with that name and restricts effective container profiles to the same choice:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          security-profile: local-apparmor
      mutate:
        - action: replace
          workloads:
            security:
              appArmorProfile:
                type: Localhost
                localhostProfile: solar-confined
      enforce:
        action: allow
        workloads:
          security:
            appArmorProfiles:
              - types: [Localhost]
                localhostProfiles:
                  - exact: [solar-confined]

Use action: merge to preserve an existing Pod profile instead of replacing it; the enforcement rule still rejects any different effective profile. Load solar-confined on every eligible node before applying the rule, or restrict placement to prepared nodes. Capsule does not load AppArmor profiles or verify that their definitions are consistent across nodes.

Registries

Configure registry-related mutations under mutate[].workloads.registries. Set imagePullPolicy for selected containers and imagePullSecrets for the Pod. The targets table shows which locations support each property. Both settings apply to Linux and Windows Pods.

Image pull policy

Set registries.imagePullPolicy to one of the native Kubernetes values:

See Kubernetes image pull policies for runtime behavior. Capsule changes the container’s policy; it does not pull images or create registry credentials.

Kubernetes fills an omitted pull policy before mutation. Capsule overwrites both that default and an explicit user value with either action: merge does not mean “only when unset” for this property. Later applicable mutation entries can overwrite it again. Conditions gate the whole entry and see changes made by preceding entries.

registries is a settings object. The mutation applies the same policy to every selected container, regardless of its image registry. To restrict image sources or validate the resulting pull policy, use registry enforcement, where registries is a list of matchers with an optional policy allowlist.

Apply different namespace profiles

This Tenant uses Always for all container groups in namespaces labeled image-profile: always-pull and allows images only from registry.k8s.io. Namespaces labeled image-profile: init-only receive the mutation only for init containers and native sidecars, preserving regular-container policies.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          image-profile: always-pull
      mutate:
        - action: replace
          workloads:
            targets: [pod]
            registries:
              imagePullPolicy: Always
      enforce:
        action: allow
        workloads:
          targets: [pod/containers, pod/initcontainers, pod/ephemeralcontainers]
          registries:
            - exact: [registry.k8s.io]
              policy: [Always]
    - namespaceSelector:
        matchLabels:
          image-profile: init-only
      mutate:
        - action: merge
          workloads:
            targets: [pod/initcontainers]
            registries:
              imagePullPolicy: Always

Existing containers and stored controller templates are unchanged. Pods created by controllers receive the mutation when admitted. Ordinary Pod updates do not rewrite pull policies, and ephemeral-container updates change only newly added containers. Image-volume pull policies are outside the mutation targets.

Image pull secrets

registries.imagePullSecrets sets the Pod’s spec.imagePullSecrets using a list of references with a name field. This is a Pod-level setting: use targets: [pod], targets: [], or omit targets. Container-only targets are rejected, including when clearing the list.

Merge retains each name already supplied on the Pod once, including ServiceAccount defaults. Replace can remove those references. Later mutation entries see and can change the resulting list. Repeated names on the incoming Pod are removed, and overlapping rules or repeated admission do not introduce duplicates. Omitting the property leaves the list untouched. Each entry accepts up to 64 references with unique, valid Secret names; duplicate configured names are rejected for both actions.

Referenced Secrets must exist in the Pod’s namespace and contain suitable registry credentials. Kubernetes accepts kubernetes.io/dockerconfigjson or kubernetes.io/dockercfg Secrets for this purpose; see image pull secrets. Capsule writes only the references: it does not create, copy, read, or verify the Secrets. Provision the credentials in each selected namespace separately, for example with TenantResource or GlobalTenantResource.

This Tenant adds a shared reference in one namespace profile, replaces the list in another, and clears it in a third. Create platform-registry or team-registry in the corresponding namespaces before workloads need to pull private images.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          pull-credentials: shared
      mutate:
        - action: merge
          workloads:
            targets: [pod]
            registries:
              imagePullSecrets:
                - name: platform-registry
    - namespaceSelector:
        matchLabels:
          pull-credentials: dedicated
      mutate:
        - action: replace
          workloads:
            registries:
              imagePullSecrets:
                - name: team-registry
    - namespaceSelector:
        matchLabels:
          pull-credentials: none
      mutate:
        - action: replace
          workloads:
            registries:
              imagePullSecrets: []

These rules apply only when a Pod is created, including Pods created by controllers. They do not rewrite controller templates, ServiceAccounts, existing Pods, or the secret list when adding ephemeral containers. Configure both imagePullPolicy and imagePullSecrets in one registries block when using the Pod target. For a container-specific pull policy, use a separate mutation entry.

Reference

This complete Tenant combines every supported workload mutation property with placement, security-profile, and image pull policy enforcement. It selects namespaces labeled example.com/application: checkout and configures workloads for Linux nodes.

The tenant-scheduler scheduler, node pool, and zone labels must exist in the cluster. Eligible nodes must support user namespaces and AppArmor. Provision the checkout-registry image pull Secret in each selected namespace. Application Pods should carry app.kubernetes.io/part-of: checkout so the spread and Pod-affinity selectors describe the intended workload.

The first mutation entry replaces the built-in scheduler default while preserving custom scheduler names. The second entry independently applies the remaining placement settings, supplies missing Pod-level security profiles, and sets all selected container root filesystems read-only and image pull policies to Always. It also adds checkout-registry to the Pod’s image pull secret references. Provide writable volume mounts for application paths that need them.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: checkout
spec:
  owners:
    - kind: User
      name: checkout-owner
  rules:
    - namespaceSelector:
        matchLabels:
          example.com/application: checkout
      mutate:
        - action: replace
          conditions:
            - name: default-scheduler
              expression: >-
                !has(object.spec.schedulerName) || object.spec.schedulerName in ['', 'default-scheduler']                
          workloads:
            placement:
              scheduler: tenant-scheduler
        - action: merge
          workloads:
            targets: [pod]
            security:
              readOnlyRootFilesystem: true
              hostUsers: false
              seccompProfile:
                type: RuntimeDefault
              appArmorProfile:
                type: RuntimeDefault
            registries:
              imagePullPolicy: Always
              imagePullSecrets:
                - name: checkout-registry
            placement:
              nodeSelector:
                kubernetes.io/os: linux
                infrastructure.example.com/pool: shared
              tolerations:
                - key: infrastructure.example.com/dedicated
                  operator: Equal
                  value: shared
                  effect: NoSchedule
              # Application Pods must carry app.kubernetes.io/part-of: checkout.
              topologySpreadConstraints:
                - topologyKey: topology.kubernetes.io/zone
                  whenUnsatisfiable: DoNotSchedule
                  maxSkew: 1
                  labelSelector:
                    matchLabels:
                      app.kubernetes.io/part-of: checkout
              affinity:
                nodeAffinity:
                  requiredDuringSchedulingIgnoredDuringExecution:
                    nodeSelectorTerms:
                      - matchExpressions:
                          - key: topology.kubernetes.io/zone
                            operator: In
                            values: [zone-a, zone-b]
                podAffinity:
                  preferredDuringSchedulingIgnoredDuringExecution:
                    - weight: 50
                      podAffinityTerm:
                        topologyKey: topology.kubernetes.io/zone
                        labelSelector:
                          matchLabels:
                            app.kubernetes.io/part-of: checkout
                            app.kubernetes.io/component: cache
                podAntiAffinity:
                  preferredDuringSchedulingIgnoredDuringExecution:
                    - weight: 100
                      podAffinityTerm:
                        topologyKey: kubernetes.io/hostname
                        labelSelector:
                          matchLabels:
                            app.kubernetes.io/part-of: checkout
      enforce:
        action: allow
        workloads:
          targets:
            - pod
            - pod/containers
            - pod/initcontainers
            - pod/ephemeralcontainers
          # Allow any image source, but require the mutated pull policy.
          registries:
            - exp: '.*'
              policy: [Always]
          security:
            seccompProfiles:
              - types: [RuntimeDefault]
            appArmorProfiles:
              - types: [RuntimeDefault]
          placement:
            nodeSelector:
              - key: {exact: [kubernetes.io/os]}
                values: {exact: [linux]}
              - key: {exact: [infrastructure.example.com/pool]}
                values: {exact: [shared]}
              - key: {exp: '^placement\.example\.com/[a-z0-9-]+$'}
                values: {exp: '^[a-z0-9-]+$'}
            tolerations:
              - key: {exact: [infrastructure.example.com/dedicated]}
                operators: [Equal]
                values: {exact: [shared]}
                effects: [NoSchedule]
              - key:
                  exact:
                    - node.kubernetes.io/not-ready
                    - node.kubernetes.io/unreachable
                operators: [Exists]
                effects: [NoExecute]
                tolerationSeconds:
                  max: 600
                  allowUnlimited: false
              - key: {exact: [node.kubernetes.io/memory-pressure]}
                operators: [Exists]
                effects: [NoSchedule]
            topologySpreadConstraints:
              - topologyKey:
                  exact: [topology.kubernetes.io/zone, kubernetes.io/hostname]
                whenUnsatisfiable: [DoNotSchedule, ScheduleAnyway]
                maxSkew: {min: 1, max: 3}
                labelSelector:
                  required: true
                  requirements:
                    - key: {exact: [app.kubernetes.io/part-of]}
                      operators: [In]
                      values: {exact: [checkout]}
            affinity:
              - types: [nodeAffinity]
                modes: [required]
                requirements:
                  - key: {exact: [topology.kubernetes.io/zone]}
                    operators: [In]
                    values: {exact: [zone-a, zone-b]}
              - types: [nodeAffinity]
                modes: [preferred]
                weight: {min: 1, max: 100}
                requirements:
                  - key: {exact: [kubernetes.io/arch]}
                    operators: [In]
                    values: {exact: [amd64, arm64]}
              - types: [podAffinity, podAntiAffinity]
                modes: [preferred]
                topologyKey:
                  exact: [topology.kubernetes.io/zone, kubernetes.io/hostname]
                namespaceScope: SameNamespace
                weight: {min: 1, max: 100}
                labelSelector:
                  required: true
                  requirements:
                    - key: {exact: [app.kubernetes.io/part-of]}
                      operators: [In]
                      values: {exact: [checkout]}
                    - key: {exact: [app.kubernetes.io/component]}
                      operators: [In, NotIn]
                      values: {exact: [api, worker, cache]}

Under enforce, the pod target validates placement and Pod-level profile defaults. The three container targets validate effective profiles and image pull policies for regular, init, and ephemeral containers, including container profile overrides. The registry matcher accepts all image sources while requiring Always. Under mutate, targets: [pod] selects all container groups for the root filesystem flag and image pull policy, and Pod-level fields, including image pull secrets, for the other properties; profile mutation still writes only Pod-level profiles. An Unconfined override or privileged container is rejected after mutation.

The toleration allowlist includes common Kubernetes-injected tolerations. Controllers such as DaemonSets may add others; include the entries needed by the workloads selected by your rule. The affinity validation uses one flat list for node affinity, Pod affinity, and Pod anti-affinity.

See the placement matcher reference for regular expressions, empty matchers, durations, selector operators, and namespace scope.

These mutations run on Pod creation. The root filesystem flag and image pull policy also apply to new ephemeral containers; the other properties are skipped on that subresource. Controller templates and existing containers are not rewritten. Profile enforcement also applies on subsequent Pod updates and pods/ephemeralcontainers updates. See Order and scope for rule composition and admission order.

2 - Enforce

Namespace rules can enforce admission behavior for selected resources in Tenant namespaces. Each enforce block can define an action and one or more matchers.

Each policy chapter identifies its API configuration path, then opens with Rule Composition: Actions and order, followed by Admission scope and limits. Policy sections explain configuration and examples. The final Reference section provides complete Tenant examples. Use the policy reference to choose a chapter.

See Order and scope for how mutation precedes enforcement, and Conditions for conditional enforcement. Audience and match expressions are documented under Rules.

Rule Composition

Actions and order

Rules are evaluated in declaration order. If multiple allow or deny rules match the same evaluated value, the last matching allow or deny rule wins. If at least one allow rule is configured for a matcher and no allow or deny rule matches the evaluated value, Capsule denies the request. In other words, allow rules create an allow-list for that matcher. audit rules are purely observational: they never influence the allow/deny decision, and report matches through Kubernetes events. Some policies also add admission warnings; see the reporting behavior documented for each policy.

Each enforce block supports an action field:

If action is omitted, Capsule treats the rule as deny.

Storage volume rules use these actions only for additional access to PVs without a Tenant ownership label. They preserve existing Tenant-owned volume access, and cannot override another Tenant’s PV label. A storage audit match never grants access.

Allow-list behavior is evaluated per matcher and per evaluated value. For example, if a registry allow rule exists for harbor/.*, a Pod image from docker.io/library/nginx:latest is denied unless another later or earlier allow rule also matches that image. Audit rules do not satisfy this allow-list requirement.

This precedence model allows both broad defaults and specific exceptions. For example, you can allow all Harbor images but deny a customer path afterwards:

rules:
  - enforce:
      action: allow
      workloads:
        registries:
          - exp: "harbor/.*"

  - enforce:
      action: deny
      workloads:
        registries:
          - exp: "harbor/customer/.*"

In this example, harbor/nginx:1.14.2 is allowed, while harbor/customer/app:1.0.0 is denied because the later, more specific deny rule also matches.

You can also deny broadly and allow a more specific exception afterwards:

rules:
  - enforce:
      action: deny
      workloads:
        registries:
          - exp: "harbor/customer/.*"

  - enforce:
      action: allow
      workloads:
        registries:
          - exp: "harbor/customer/prod-image/.*"

In this example, harbor/customer/test-image/app:1.0.0 is denied, while harbor/customer/prod-image/app:1.0.0 is allowed.

Audit

Use action: audit to observe workload usage without directly blocking the request. Audit rules emit Kubernetes events and add warnings to the admission response, but they do not allow or deny the request. If an allow-list is active for the same matcher and no allow rule matches the evaluated value, the request is still denied even when an audit rule matches.

For registry enforcement:

---
apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  ...
  rules:
    - enforce:
        action: audit
        workloads:
          targets:
            - pod/containers
          registries:
            - exp: "docker.io/.*"

Applying a Pod with docker.io/library/nginx:latest succeeds in this audit-only example because no registry allow-list is configured. The API server response contains an admission warning and Capsule emits a related event for the Pod.

For QoS enforcement:

rules:
  - enforce:
      action: audit
      workloads:
        qosClasses:
          - Burstable

Applying a Burstable Pod succeeds in this audit-only example because no QoS allow-list is configured. Capsule emits an event and returns an admission warning.

For scheduler enforcement:

rules:
  - enforce:
      action: audit
      workloads:
        placement:
          schedulers:
            - exact:
                - custom-scheduler

Applying a Pod with spec.schedulerName: custom-scheduler succeeds in this audit-only example because no scheduler allow-list is configured. Capsule emits an audit event and returns an admission warning.

When audit rules are used together with allow rules, the matching value must still be allowed explicitly. For example, an audited registry reference that does not match any registry allow rule is denied by the allow-list, but Capsule still emits the audit event before denying the request.

Admission scope and limits

Enforcement runs during admission for resources in the namespaces selected by the rule. Audience filters the caller, and conditions decide whether an enforcement block participates. Each policy chapter lists its supported resources, operations, subresources, and handling of missing values.

Mutation runs before validation. An allow decision applies to its evaluated policy and value; other applicable checks, RBAC, and Kubernetes API validation must still pass. In particular, an enclosing action: audit does not disable resource defaulting or mutation.

Enforcement evaluates incoming writes. Changing a rule or namespace profile does not by itself repair existing resources or revoke established bindings. Storage ownership, resource mutation, and checks involving related resources have specific limits documented in their chapters.

Reference

The following fields belong to spec.rules[].enforce. Each policy page includes a complete Tenant example and explains its supported resources, matching behavior, and admission scope.

To disallow CIDR-based ingress and egress grants in every namespace of a Tenant:

rules:
  - enforce:
      action: deny
      network:
        policies:
          ingress:
            cidrs:
              - 0.0.0.0/0
              - ::/0
          egress:
            cidrs:
              - 0.0.0.0/0
              - ::/0

Place this rules block under Tenant.spec. The rule rejects grants from or to any IPv4 or IPv6 CIDR, as well as unrestricted ingress or egress rules with omitted peers. Selector-based peers and empty grant lists pass their CIDR check. Each direction is independent; omit ingress or egress to leave that direction unconstrained. The NetworkPolicy reference shows how later rules can permit approved ranges in selected namespaces.

2.1 - Workloads

Workload enforcement is configured under spec.rules[].enforce.workloads. Use targets to select native workload kinds or locations inside their Pod specs. A targets-only rule matches the selected kinds themselves. When workload policies are present, targets scope those policies: resource management, OCI registries, scheduler names, QoS, placement, security profiles, and PodDisruptionBudgets.

Rules use the shared namespace selection, audiences, conditions, and actions and order. See Reference for a complete Tenant example.

Rule Composition

Actions and order

Rules are evaluated in declaration order after namespace selection, audience, and condition filtering. The last matching allow or deny decision wins for each evaluated value. An omitted action defaults to deny.

Each policy and value is evaluated independently. Allowing a registry does not bypass a scheduler, security, placement, or other applicable constraint.

For constraints on requests and limits and PodDisruptionBudgets, deny rejects violations and allow requires compliance. Their policy sections explain which values constitute a match and how audit events and admission warnings are reported.

Resource policies also have a mutation phase. The last applicable policy is effective for each target, resource, and request or limit field. The enclosing action: audit does not disable resource mutation. See Rule order and policy overrides for how Preserve and Default reset earlier constraints.

Admission scope and limits

Workload rules govern admission of the selected resources and Pod-spec locations. Workload Targets maps kinds to their Pod specs; the controller and Pod tables show where each policy takes effect.

A controller write and the Pods it later creates are separate admissions, often with different callers. Include the required targets and audiences for both paths. Conditions inspect the actual incoming resource, which can also be a PDB or a Scale object.

Kubernetes validation, LimitRanges, ResourceQuotas, and other admission policies still apply after Capsule’s checks. See Admission lifecycle for the resource policy stages and Interaction with Kubernetes resource controls for their combined behavior.

Workload Targets

Configure targets under spec.rules[].enforce.workloads.targets. The same list selects workloads for resource, registry, scheduler, QoS, placement, security, and PodDisruptionBudget policies; individual policies do not have separate target lists.

• With no workload policies, targets apply the rule’s action to the selected workload kinds. For example, targets: [daemonset] with action: deny rejects DaemonSets.
• With workload policies, targets scope those policies to the selected workloads and Pod-spec locations. Adding a policy means the rule checks that property instead of restricting the kind itself. Use separate rule entries when you need both kind restrictions and property checks.

Omitted or empty targets preserve the default Pod scopes described below and do not enable controller checks. An empty workload block has no effect. Namespace selectors, audiences, and enforce.conditions apply to both forms.

Each target selects the object being admitted. With workload policies configured, Capsule reads the Pod spec at the following location:

For example, cronjob/containers checks regular containers at spec.jobTemplate.spec.template.spec.containers[] on the CronJob itself. It does not select a Job or Pod by following its CronJob owner.

Requests match their own API group and kind, without following owner references. A custom resource named DaemonSet in another API group is not a native target. Targets use the exact lowercase values shown here; wildcards such as pod/*, deployment/*, and * are not supported.

Migration: targets-only rules previously had no effect. They now apply the action to the selected kinds, and an omitted action defaults to deny. Remove unused targets-only entries before upgrading if they were placeholders.

Controller targets

Controller targets check the stored Pod template during controller creation and main-resource updates. They do not wait for a Pod to be created. A denial rejects the controller write; an accepted template supplies the values Kubernetes later uses to create child workloads. Existing children are not rewritten by admission.

The table uses cronjob as an example. The same suffixes and policy scopes apply to every controller kind listed above, using that kind’s Pod-spec path. Paths in this table are relative to spec.jobTemplate.spec.template.spec. ✅ indicates support; ❌ means the policy does not apply to that target. Only policies configured in the rule are evaluated.

For example, deployment/initcontainers has the same scope as cronjob/initcontainers, but reads spec.template.spec.initContainers[]. Controller templates do not support /ephemeralcontainers. Resource policies cannot be combined with volume targets.

The placement row covers node selectors, tolerations, topology spread, and affinity. Scheduler and QoS policies always evaluate the whole selected Pod spec, even with a container or volume suffix. For example, cronjob/initcontainers with a scheduler policy checks spec.jobTemplate.spec.template.spec.schedulerName.

A whole-controller target includes container resources and image references; the explicit pod target has the narrower scope in the Pod table. For security profiles, the effective value is the container override or its inherited Pod default. A whole-controller target does not independently require a Pod-level default when every container supplies its own allowed profile.

Whole-controller PDB checks use the Pod template’s labels to find matching budgets. CronJobs, Jobs, and DaemonSets support overlap and unhealthy eviction policy checks, but not evictableReplicas. See the PDB target table for the complete mapping.

Resource request/limit policies also mutate the selected template locations on controller creation and updates. Targets do not extend mutate[].workloads to controllers; mutations configured there remain limited to Pod creation. See Admission lifecycle.

Conditions see the whole admitted controller: use object.spec.template.spec for a Deployment and object.spec.jobTemplate.spec.template.spec for a CronJob. Events concern that controller object. Namespace selection, audiences, and conditions must match each request independently.

Example: CronJob admission

This rule denies a forbidden scheduler or image in Deployment and CronJob templates while permitting compliant ones:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          targets: [deployment, cronjob]
          placement:
            schedulers:
              - exact: [forbidden-scheduler]
          registries:
            - exact: ['example.com/blocked/app:v1']

For the CronJob path, assuming the namespace, audience, and conditions match:

To check all three stages, include cronjob, job, and the Pod targets needed for the policy. For registry checks, use pod/containers, pod/initcontainers, pod/ephemeralcontainers, and/or pod/volumes for the image locations you want to cover; pod alone does not select images. Controller-created Jobs and Pods can have different callers, so include those identities in any audience filter.

With no workload policies, targets: [cronjob] instead acts on the kind: deny rejects CronJobs, while allow establishes a workload-kind allow-list. A targets-only allow-list must also allow job and pod for scheduled workloads to run. See Select Workloads.

Pod targets

When workload policies are present, Pod targets select these locations. ✅ indicates support; ❌ means the policy does not apply to that target.

For seccomp and AppArmor, an effective profile resolves a container override before the Pod default. Init containers include restartable sidecars. Selecting pod alone checks the default and leaves container overrides unchecked. See Target security profiles for a complete Tenant and a comparison of these scopes.

This table describes enforcement. Profile mutations under mutate[].workloads set Pod-level defaults on Pod creation, using pod or omitted mutation targets. Neither merge nor replace modifies container profile overrides. For security.readOnlyRootFilesystem and registries.imagePullPolicy mutations, pod selects all container groups and container targets can narrow the selection. See the separate mutation targets table. Enforcement targets do not control mutation.

Scheduler and QoS policies always evaluate the whole Pod selected by any Pod target. For example, pod/containers does not limit QoS calculation to regular containers. Resource policies cannot be combined with targets for ephemeral containers or volumes.

Omitting targets, or setting it to [], selects all compatible Pod locations: Pod-level resources, regular and init container resources, regular/init/ephemeral container images, image volumes, and Pod placement fields. Scheduler and QoS checks also apply. Profile policies check effective regular, init, and ephemeral container profiles. PDB overlap and unhealthy eviction policies check the Pod; eviction-count bounds require an explicit supported controller target. Resource-name compatibility is described under Targeting resource locations.

An explicit targets: [pod] is narrower than omitted targets: it selects Pod-level resources, placement, and security-profile defaults, together with scheduler and QoS checks. It does not select container resources or any image references. List the desired Pod parts explicitly when narrowing container, image, or profile policies.

For example, deny matching images only in init containers:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          targets: [pod/initcontainers]
          registries:
            - exp: "harbor/init-only/.*"

The same image reference in a regular container, ephemeral container, or image volume is unaffected by this rule. Combine targets to check multiple locations:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          targets: [pod/containers, pod/ephemeralcontainers]
          registries:
            - exp: "debug/.*"

This checks regular and ephemeral container images. It does not check init containers or image volumes.

Targets without policies match the whole kind. A targets-only rule with targets: [pod/containers] and action: deny rejects Pods, just like targets: [pod]. A part suffix narrows property checks only when workload policies are configured.

Target security profiles

This complete Tenant gives namespaces two different profile policies. Namespaces labeled profile-scope: pod-only require RuntimeDefault in the Pod’s security context. Namespaces labeled profile-scope: containers require RuntimeDefault for every effective regular, init, and ephemeral container profile. Namespaces with neither label are unaffected by these rules.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          profile-scope: pod-only
      enforce:
        action: allow
        workloads:
          targets: [pod]
          security:
            seccompProfiles:
              - types: [RuntimeDefault]
            appArmorProfiles:
              - types: [RuntimeDefault]
    - namespaceSelector:
        matchLabels:
          profile-scope: containers
      enforce:
        action: allow
        workloads:
          targets:
            - pod/containers
            - pod/initcontainers
            - pod/ephemeralcontainers
          security:
            seccompProfiles:
              - types: [RuntimeDefault]
            appArmorProfiles:
              - types: [RuntimeDefault]

These rules supply no defaults. For Linux Pods, each mechanism is checked independently:

List only pod/initcontainers to restrict the profile checks to init containers. Combine pod with the three container targets to require both an allowed Pod default and allowed effective container profiles. Omitting targets checks all three container groups without independently requiring a Pod default.

The security reference combines Pod-level defaulting with container enforcement. A container override survives mutation and must then pass the selected enforcement checks, including on pods/ephemeralcontainers updates.

Select Workloads

A targets-only allow rule establishes an allow-list across the eight supported native workload kinds. Other resource kinds remain outside this allow-list. Allow controller-created children explicitly:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: allow
        workloads:
          targets: [deployment, replicaset, pod]

This allows Deployments, ReplicaSets, and Pods while rejecting the other supported native workload kinds. Allowing a Deployment alone does not allow its ReplicaSets or Pods: each request is evaluated separately. Kind restrictions apply to creation and main-resource updates, not deletion or subresources.

Deny DaemonSets

Add a targets-only rule under Tenant.spec.rules to deny DaemonSets in namespaces labeled env: test:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - namespaceSelector:
        matchLabels:
          env: test
      enforce:
        action: deny
        workloads:
          targets: [daemonset]

This rejects DaemonSet creation and main-resource updates in the selected namespaces. It does not remove existing DaemonSets or block deletion or subresources. Other workload kinds and non-selected namespaces are unaffected by this rule. To cover all namespaces in the Tenant, omit namespaceSelector.

Use action: audit to record matching requests without blocking them. For kind restrictions, the last matching allow or deny rule wins; audit does not change that decision.

Resource Management

Configure CPU, memory, and other resource requests and limits, together with Pod QoS policies.

Requests and Limits

Resource policies let a Tenant administrator normalize and enforce the requests and limits of Pods created in Tenant namespaces. They cover common requirements that a Kubernetes LimitRange cannot express directly, including:

• always removing a resource limit;
• making a limit equal to its request;
• defaulting a missing request or limit without replacing an explicit value;
• deriving a missing limit from a request using a maximum ratio; and
• rejecting or auditing explicit limits that exceed that ratio.

Resource policies are configured under spec.rules[].enforce.workloads.resources. The requests and limits maps are keyed by Kubernetes resource name. Each map entry contains a case-sensitive policy and, for policies that need one, a value.

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  rules:
    - enforce:
        action: deny
        workloads:
          resources:
            limits:
              cpu:
                policy: Remove
              memory:
                policy: MatchRequest

At every compatible resource location, this example produces the following behavior:

• CPU limits are removed, even when the submitted Pod defines them;
• memory limits are set to the corresponding memory requests; and
• because targets is omitted, the policy applies to Pod-level resources, regular containers, and init containers.

Before and after admission

Consider this submitted Pod:

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  containers:
    - name: api
      image: registry.example.com/api:1.0.0
      resources:
        requests:
          cpu: 250m
          memory: 512Mi
        limits:
          cpu: "1"
          memory: 1Gi

Capsule admits it with the equivalent resource configuration:

resources:
  requests:
    cpu: 250m
    memory: 512Mi
  limits:
    memory: 512Mi

The CPU request is untouched, the CPU limit is removed, and the memory limit is replaced with the memory request. Because targets is omitted, Capsule applies the same policy independently to spec.resources, every regular container, and every init container in the Pod. The submitted example has no Pod-level or init container resources, so those locations remain empty.

If MatchRequest finds neither a request nor a limit, the resource is compliant and remains undefined. If it finds a limit without a corresponding request, it cannot derive a replacement and the final state violates the policy. With action: deny the Pod is rejected; with action: audit Capsule admits it and emits an audit event and admission warning.

Policy reference

After starting with the common example above, use this reference to choose the precise behavior for each request and limit.

Requests

The following policies are supported under resources.requests:

Default a request without overriding tenant workloads that already specify it:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          resources:
            requests:
              cpu:
                policy: Default
                value: 100m
              memory:
                policy: Default
                value: 256Mi

If a container requests 500m CPU, Capsule preserves 500m. If the CPU request is missing, Capsule adds 100m.

Remove an extended resource request:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          targets:
            - pod/containers
          resources:
            requests:
              example.com/temporary-device:
                policy: Remove

Resource names must be valid Kubernetes qualified names. Custom and extended resource names can be used for container and init-container policies, subject to the normal Kubernetes rules for that resource.

Limits

The following policies are supported under resources.limits:

Default is a fill-only policy. It does not mean that every limit must equal the configured value. Use MatchRequest when Capsule should own the limit and keep it equal to the request, or Ratio when explicit tenant values are allowed within a bounded range.

Ratio limits

Ratio defines the maximum permitted limit as a multiple of the request. It is available only for limits and supports these resource names:

The ratio must be greater than or equal to 1. Quote fractional ratios in YAML for clarity, for example "1.5".

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          targets:
            - pod/containers
          resources:
            limits:
              memory:
                policy: Ratio
                value: "1.5"

For a memory request of 1Gi, the maximum limit is 1536Mi:

An explicit limit is never reduced by Ratio. This is deliberate: preserving the submitted value allows allow, deny, and audit to decide how a ratio violation should be handled. Use MatchRequest when the limit should always be rewritten instead.

Ratio requires a positive request. When the request is missing or zero, Capsule cannot calculate a default limit. The missing or non-positive request is therefore a policy violation. A deny action blocks it, an audit action reports it, and an allow action treats it as an allow-list miss and blocks it.

Capsule calculates ratios without floating-point arithmetic and rounds down so that the generated limit never exceeds the configured factor. For example, a CPU request of 101m with a ratio of 1.5 produces a limit of 151m, not 152m.

Targeting resource locations

Resource policies reuse enforce.workloads.targets to select resource locations. See Pod targets for the location table and Workload targets for controller targets. Ephemeral containers and volumes cannot be selected for resource policies.

When targets is omitted or empty, each resource policy applies to every compatible location: Pod-level spec.resources, regular containers, and init containers. An explicit targets list narrows that default.

Compatibility is evaluated per resource name. Kubernetes Pod-level resources support only cpu, memory, and huge-page resources. With omitted targets, those names apply at all three locations, while other valid names such as ephemeral-storage and extended resources apply only to regular and init containers. Capsule skips those incompatible names at spec.resources; it does not reject the rule or discard their container policies.

Only regular containers:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          targets:
            - pod/containers
          resources:
            limits:
              cpu:
                policy: Remove

Only init containers:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          targets:
            - pod/initcontainers
          resources:
            requests:
              cpu:
                policy: Default
                value: 25m

Both regular and init containers, explicitly:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          targets:
            - pod/containers
            - pod/initcontainers
          resources:
            limits:
              memory:
                policy: MatchRequest

Only Pod-level resources:

apiVersion: capsule.clastix.io/v1beta2
kind: Tenant
metadata:
  name: solar
spec:
  owners:
    - kind: User
      name: solar-owner
  rules:
    - enforce:
        action: deny
        workloads:
          targets:
            - pod
          resources:
            requests:
              cpu:
                policy: Default
                value: 500m
              memory:
                policy: Default
                value: 1Gi
            limits:
              cpu:
                policy: Ratio
                value: "2"
              memory:
                policy: Ratio
                value: "1.5"