#Viewing and Managing Security Policies

Alauda Container Security offers both default and customizable security policies to help you prevent high-risk deployments and respond to runtime incidents in your container environment.

---

#Policy Categories

Policies are organized by type and function for easier management and search. Default categories include:

• Anomalous Activity
• Cryptocurrency Mining
• DevOps Best Practices
• Docker CIS
• Kubernetes
• Kubernetes Events
• Network Tools
• Package Management
• Privileges
• Security Best Practices
• Supply Chain Security
• System Modification
• Vulnerability Management
• Zero Trust

To manage categories:

1. Go to Platform Configuration > Policy Management.
2. Click the Policy Categories tab.
3. Create, view, or manage categories as needed.

---

#Policy Lifecycle Stages

When creating or editing a policy, you can specify one or more lifecycle stages:

• Build: Checks image fields (e.g. CVEs, Dockerfile instructions).
• Deploy: Includes build-time checks and cluster configuration (e.g. privileged mode).
• Runtime: Adds process execution and runtime event checks.

---

#Policy Criteria and Attributes

Policies are triggered by specific criteria (attributes). The following tables summarize common attributes and their descriptions. For details on allowed values, operators, and applicable phases, see the notes below each table.

#Image Registry and Contents

Operators: Regex, NOT, AND, OR, OR only, AND only, None, etc.
Phases: Build, Deploy, Runtime

---

#Container Configuration

Operators: Regex, AND, OR, None, etc.
Phases: Deploy, Runtime

---

#Deployment Metadata

Operators: Regex, AND, OR, NOT, None, etc.
Phases: Deploy, Runtime

---

#Storage and Networking

Operators: Regex, AND, OR, NOT, None, etc.
Phases: Deploy, Runtime, Runtime (Network)

---

#Process Activity (Runtime Only)

Operators: Regex, AND, OR, NOT, None, etc.
Phases: Runtime (Process)

---

#Kubernetes Access and Events

Operators: Regex, AND, OR, NOT, None, etc.
Phases: Deploy, Runtime, Runtime (K8s Events), Runtime (Audit Log)

---

#Policy Enforcement

Alauda Container Security supports multiple enforcement types depending on the policy phase:

• Build-time enforcement: Fails CI builds if images violate policy. The API returns a non-zero exit code, which can be used to fail the build pipeline.
• Deploy-time enforcement: Integrates with Kubernetes admission controllers and Alauda Container Platform admission plugins to block noncompliant workloads. Enforcement can be:
  • Hard enforcement: Admission controller blocks creation or update of violating deployments.
  • Soft enforcement: Sensor scales violating deployments to zero replicas, preventing pods from being scheduled.
• Runtime enforcement: When enabled, any runtime activity within a pod that violates this policy will cause the pod to be automatically deleted. Violations triggered via the API server will also be blocked.

Note: By default, administrative namespaces such as stackrox, kube-system, cpaas-system,and istio-system are excluded from enforcement blocking. Requests from service accounts in system namespaces are also bypassed.

To apply policy changes to existing deployments, use Policy Management > Reassess All to trigger enforcement on all deployments.

---

#Exporting and Importing Policies

You can share security policies between different Central instances by exporting and importing policies as JSON files.

#Exporting a Policy

1. Go to Platform Configuration > Policy Management.
2. Select the policy to export.
3. Click Actions > Export policy to JSON.

#Importing a Policy

1. Go to Platform Configuration > Policy Management.
2. Click Import Policy.
3. Upload the JSON file and click Begin Import.

Import Handling:

• If the imported policy UID and name are unique, a new policy is created.
• If the UID matches but the name differs, you can keep both (new UID) or replace the existing policy.
• If the name matches but the UID differs, you can keep both (rename) or replace the existing policy.
• If both UID and name match, Alauda Container Security checks if the criteria match. If so, the existing policy is kept; otherwise, you can keep both (rename) or replace.

Important:

• When importing into the same Central instance, all exported fields are used.
• When importing into a different Central instance, certain fields (e.g. cluster scopes exclusions notifications) are omitted and cannot be migrated.