Improve posture with Network Policies and Seccomp Profiles
Copy link

Network Policies and Seccomp Profiles help you reduce the attack surface of Kubernetes workloads by enforcing least-privilege controls at the network and system call levels.

  • Network Policies restrict pod-to-pod and pod-to-external communication.
  • Seccomp Profiles restrict the Linux system calls containers are allowed to execute.

Together, these controls improve runtime security posture by limiting both communication paths and kernel-level capabilities.

With this feature, you can:

  • Identify workloads missing Network Policies or Seccomp profiles
  • Detect overly permissive configurations
  • Automatically generate optimized policies
  • Compare recommended configurations with current settings
  • Deploy policies to enforce least privilege

Before you begin
Copy link

Before you can generate network policies or Seccomp profiles for your Kubernetes cluster, you must enable Kubernetes Security Guardrails and Container Runtime Security.

Improve posture with Seccomp Profiles
Copy link

Seccomp (Secure Computing Mode) profiles  restrict the system calls that containers can execute. By limiting available syscalls to only those required by a workload, you reduce the likelihood of privilege escalation and kernel-level exploitation.

⚠️

Use the Command Platform to access Container Runtime Security

Access Container Runtime Security from the Command Platform to authenticate and take action on findings. If you open Cloud Security outside the Command Platform, you can view detections, but some features are unavailable.

To view seccomp profiles:

  1. Log in to the Command Platform .
  2. Go to Controls & Compliance > Runtime.
  3. Click Manage Rules and Policies. The Container Runtime Security feature opens to the Threat Detection page.
  4. Click Seccomp Profiles.

The Seccomp Profile view displays the Profile Status for each workload:

  • Missing: No Seccomp profile is configured for the workload.
  • Missing runtime info: Required runtime data is unavailable to generate a profile. Restart the workload.
  • Optimized: A Seccomp profile is configured and allows only the syscalls used by workload containers.
  • Overly Permissive :A Seccomp profile is configured but allows more syscalls than the workload requires.

This view also provides insight into syscall usage:

  • Used: The actual syscalls executed by workload containers.
  • Unused: If the profile is missing, this represents all syscalls not used. If the profile is overly permissive, this represents syscalls allowed by the profile but not used by the workload.

Generate and deploy a Seccomp profile

You can generate a Seccomp profile when a workload status is Missing or Overly Permissive.

To generate a Seccomp profile:

  1. Log in to the Command Platform .
  2. Go to Controls & Compliance > Runtime.
  3. Click Manage Rules and Policies. The Container Runtime Security feature opens to the Threat Detection page.
  4. Click Seccomp Profiles.
  5. Select a workload.
  6. Click Generate Profile. A side panel expands to show two artifacts for your workload:
  • Seccomp Profile: A custom resource that defines the optimized Seccomp configuration for each container in the workload and specifies the host file paths for generated configuration files.
  • Updated workload resource: A new version of the workload manifest that references the generated Seccomp profile and applies the required Seccomp configuration to each container.

After you generate a profile, you must deploy it.

To deploy a Seccomp profile:

  1. From the same side panel, click Apply Seccomp profile.
  2. Click Apply.

After deployment, the workload enforces the optimized Seccomp configuration.

Improve posture with network policies
Copy link

Kubernetes network policies control how pods communicate with:

  • Other pods
  • Namespaces
  • External IP ranges

If a pod is selected by one or more NetworkPolicy objects, it accepts only traffic explicitly allowed by at least one policy. Pods not selected by any policy are fully accessible. Pods cannot block communication with themselves and traffic to and from the node hosting the pod is always allowed.

If no network policies exist in a namespace:

  • All ingress traffic is allowed.
  • All egress traffic is allowed.

You can modify this behavior by applying default isolation policies, but network policies can be complex:

  • Defining policies across multiple pods, services, and namespaces is time-consuming.
  • Policies operate at a granular level, increasing risk of misconfiguration.
  • Limited visibility into runtime communication makes policy creation difficult.
  • Large or distributed clusters increase policy complexity.

To view network policies:

  1. Log in to the Command Platform .
  2. Go to Controls & Compliance > Runtime.
  3. Click Manage Rules and Policies. The Container Runtime Security feature opens to the Threat Detection page.
  4. Click Network Policies.

Each workload displays one of the following statuses:

  • Network Policy Applied: At least one associated pod has a network policy.
  • Network Policy Recommended: No network policy exists for the workload.
  • Missing Runtime Info: Required runtime data is unavailable to generate a policy. Restart the workload.

Generate a network policy

When a container or pod inside a cluster with a sensor is started:

  1. The system enters a learning phase.
  2. Runtime communication patterns are observed.
  3. Observed traffic is stored in a custom resource.
  4. A least-privilege policy is generated based on actual behavior.

To view learned communication patterns:

kubectl get networkneighborhoods -n <namespace> <workload-kind>-<workload-name>

To restart the learning phase:

kubectl delete networkneighborhoods -n <namespace> <workload-kind>-<workload-name>

To generate a network policy:

  1. Log in to the Command Platform .
  2. Go to Controls & Compliance > Runtime.
  3. Click Manage Rules and Policies. The Container Runtime Security feature opens to the Threat Detection page.
  4. Click Network Policies.
  5. Select a cluster and namespace.
  6. Select one or more workloads.
  7. Click Generate policy.
  8. Download the generated YAML files.
  9. Apply the policy files to your cluster.

The generated policy follows a least-privilege model and allows only observed traffic.

Example deny network policies
Copy link

Default deny all ingress traffic

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

Default deny all egress traffic

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress