Configuring Seccomp profiles for the Anjuna Nitro Launcher

The Anjuna Nitro Runtime relies on vsock (VM sockets) to communicate with enclaves. In restricted environments, vsock operations might be blocked by policies, such as the default Kubernetes Seccomp profile.

In this type of scenario, the default Seccomp profile is not compatible with the Anjuna Nitro Runtime. You must either disable Seccomp or use a custom profile.

For this reason, the recommended Anjuna Kubernetes Toolset for AWS EKS configuration disables Seccomp for the Anjuna Nitro Launcher container, by setting seccompProfile.type to Unconfined in the launcherContainerSecurityContext Helm chart parameter.

You can configure Seccomp profiles for the Anjuna Kubernetes Toolset for AWS EKS via that same launcherContainerSecurityContext parameter, which takes a standard v1.SecurityContext Kubernetes field. Refer to Configuring and deploying the Anjuna Kubernetes Toolset for the default value of this parameter and the other Launcher security context settings.

Configure the Seccomp profile at the container scope, through launcherContainerSecurityContext, and not at the Pod scope through launcherPodSecurityContext. Kubernetes gives the container seccompProfile precedence over the Pod one, so the Unconfined profile in launcherContainerSecurityContext overrides anything set at the Pod scope.

This setting will not affect Pods that do not run with Anjuna. Existing Anjuna Confidential Pods need to be restarted for the changes to take effect.

The Seccomp profile applies to the Anjuna Nitro Launcher component, not to the application running inside of the enclave. The enclave is a restricted environment, and the Anjuna Nitro Runtime provides mechanisms to ensure its behavior is correct.

Using a custom Seccomp profile

To use a custom Seccomp profile, you need to first deploy the profile to all worker Nodes that run Anjuna Confidential Pods, as described below.

Deploying a Seccomp profile

This section assumes that you are a Cluster Administrator and have the following:

  • SSH access to the worker Nodes

  • Permissions to install the Anjuna Kubernetes Toolset for AWS EKS to the cluster

To deploy a Seccomp profile to the worker Nodes, you need to SSH into each Node and place the custom profile under /var/lib/kubelet/seccomp/profiles. This operation can be automated via projects such as the Security Profiles Operator.

Anjuna publishes a minimal profile for the Launcher, anjuna-minimal-seccomp-v1.json, which is tested against each Anjuna Nitro Runtime release.

Add it to your worker nodes as /var/lib/kubelet/seccomp/profiles/anjuna-minimal.json.

Every node that runs Anjuna Confidential Pods needs the profile, including nodes added to the cluster later by scaling or node replacement.

If you create your cluster with the Anjuna Terraform scripts, set the launcher_seccomp_profile variable to the profile’s path to ensure that it is installed on every node. This variable defaults to null, which installs no profile and leaves the Launcher Unconfined. Setting it also generates the values.yaml file with the launcherContainerSecurityContext seccompProfile field already set to the installed profile, so you do not need to configure it as described below.

If you prefer a more permissive starting point, the default Seccomp profile that ships with Docker and containers excludes vsock operations. That profile can be changed to allow vsock operations while still enforcing all the other restrictions, as illustrated in the diff below:

       "names": [
               "socket"
       ],
<      "action": "SCMP_ACT_ALLOW",
<      "args": [
<              {
<                      "index": 0,
<                      "value": 40,
<                      "op": "SCMP_CMP_NE"
<              }
<      ]
---
       "names": [
               "socket"
       ],
>      "action": "SCMP_ACT_ALLOW"

The full updated example is available here, and can be added to your worker Nodes as /var/lib/kubelet/seccomp/profiles/anjuna.json.

You can also take either example as a starting point and write a fine-grained profile that matches your use case.

Using a custom Seccomp profile

Once the custom profile is deployed to your worker Nodes, you can set it as the default for the Anjuna Nitro Launcher Pod, by setting the parameter in your Helm chart values.yaml file. The example below assumes that the profile was added to /var/lib/kubelet/seccomp/profiles/anjuna-minimal.json:

Set the seccompProfile field of the launcherContainerSecurityContext block in your Helm chart values.yaml file, leaving the rest of the block as it is:

# values.yaml
launcherContainerSecurityContext:
  allowPrivilegeEscalation: true
  capabilities:
    drop: ["ALL"]
    add: ["CHOWN", "MKNOD", "FOWNER", "DAC_OVERRIDE"]
  seccompProfile:
    type: Localhost
    localhostProfile: profiles/anjuna-minimal.json
The launcherContainerSecurityContext value replaces the recommended block rather than merging with it. Restate allowPrivilegeEscalation and capabilities as shown above, or the Launcher fails to start enclaves and AnjunaFS mounts break at run time.
If you are updating this configuration in a live Anjuna Toolset, make sure to restart the Anjuna Webhook Pods so that they pick up the new values.

This will ensure that all new Anjuna Nitro Launcher Pods use the custom Seccomp profile that you installed to worker Nodes under /var/lib/kubelet/seccomp/profiles/anjuna-minimal.json.

This is the recommended way of configuring a custom Seccomp profile for the Anjuna Nitro Launcher Pod.

Alternatively, if you cannot configure the Anjuna Kubernetes Toolset for AWS EKS or the cluster Nodes, you can configure the Seccomp profile directly from each Pod specification. Configure the Seccomp profile by setting the nitro.k8s.anjuna.io/launcherContainerSecurityContext annotation to a JSON string that contains a valid Launcher SecurityContext field:

kind: Pod
spec:
  name: my-application
  metadata:
    labels:
      nitro.k8s.anjuna.io/managed: "yes"
    annotations:
      nitro.k8s.anjuna.io/launcherContainerSecurityContext: '{"seccompProfile": {"type": "Localhost", "localhostProfile": "profiles/anjuna-minimal.json"}}'

The annotation is merged onto the resolved container security context, so the enforced allowPrivilegeEscalation and capabilities fields are kept as long as the annotation does not name them. Setting the profile in the Pod’s own .spec.containers[].securityContext has no effect, because the enforced Unconfined profile is applied on top of it.

If an invalid security context is provided via the annotation, the Pod creation will fail.

Disabling Seccomp

Disabling Seccomp might not be allowed or recommended by your organization.

Seccomp is already disabled for the Anjuna Nitro Launcher in the recommended Anjuna Kubernetes Toolset for AWS EKS configuration. To disable Seccomp explicitly, set the parameter in your Helm chart values.yaml file:

# values.yaml
launcherContainerSecurityContext:
  allowPrivilegeEscalation: true
  capabilities:
    drop: ["ALL"]
    add: ["CHOWN", "MKNOD", "FOWNER", "DAC_OVERRIDE"]
  seccompProfile:
    type: Unconfined

This is the recommended way of disabling Seccomp for the Anjuna Nitro Launcher Pod.

If you are updating this configuration in a live Anjuna Toolset, make sure to restart the Anjuna Webhook Pods so that they pick up the new values.

Alternatively, if you cannot configure the Anjuna Kubernetes Toolset for AWS EKS or the cluster Nodes, you can configure the Seccomp profile directly from each Pod specification. Configure the Seccomp profile by setting the nitro.k8s.anjuna.io/launcherContainerSecurityContext annotation to a JSON string that contains a valid Launcher SecurityContext field:

kind: Pod
spec:
  name: my-application
  metadata:
    labels:
      nitro.k8s.anjuna.io/managed: "yes"
    annotations:
      nitro.k8s.anjuna.io/launcherContainerSecurityContext: '{"seccompProfile": {"type": "Unconfined", "localhostProfile": null}}'
Since the annotation is merged into the existing securityContext field value, setting "localhostProfile": null alongside "type": "Unconfined" ensures that the resulting seccompProfile field is well-formed.

If an invalid security context is provided via the annotation, the Pod creation will fail.