Security Contexts for TPA and Sidecar Containers

  • Published on Jan 31, 2025
  • 3 minute(s) read
Prev Next

Security is a critical aspect of deploying applications in Kubernetes. To ensure that the Traceable Platform Agent (TPA) and its sidecar containers operate securely, you can configure Pod Security Contexts and Container Security Contexts. These settings allow you to define the pod or container-level security attributes, ensuring fine-grained control and compliance with security best practices.

This guide walks you through the configurations available for TPA and sidecar containers, explaining how to use and customize these contexts to enhance your deployment's security.

Before you begin

Before you begin, ensure the following:

  • You have a Kubernetes cluster where TPA is deployed.

  • You have access to the Helm chart used to deploy Traceable Platform Agent.

  • It is recommended that you familiarize yourself with Kubernetes security contexts. For a deeper understanding, refer to the official Kubernetes documentation.

Pod Security Context

The Pod Security Context applies security settings to the entire pod, impacting all containers within it unless overridden at the container level. This is configured using the tpaPodSecurityContext field in the Helm chart.

Configuration Example

Here’s a sample configuration for a pod-level security context: 

# traceable-agent pod securityContext. This can be overridden using the container securityContext config.
tpaPodSecurityContext:
  runAsUser: 1000
  fsGroup: 2000
  seLinuxOptions:
    level: "s0:c123,c456"

Explanation of Values

  • runAsUser: 1000: Specifies that the processes in the pod will run as the user with the ID 1000. In Linux-based systems, user IDs correspond to specific users. For example, 1000 is typically assigned to the first non-root user created on the system.

  • fsGroup: 2000: Specifies that files created within the pod's volumes will be owned by the group with the ID 2000. This ensures shared access to files by all containers in the pod that are part of this group.

  • seLinuxOptions: level: "s0:c123,c456": Defines SELinux (Security-Enhanced Linux) context options. The level indicates the security context for processes and files, with c123,c456 representing specific categories to isolate resources securely.

Note

Containter-level security context can override these settings for individual containers.

Container Security Context

The Container Security Context provides security settings for individual containers, allowing for more granular control. This is configured using the securityContext field and related fields in the Helm chart.

Configuration Fields

  • useCustomSecurityContext: Set to true to enable custom container-level security contexts.

  • commonContainerSecurityContext: A shared security context configuration applied to all containers.

  • Individual container-specific security contexts, such as:

    • securityContext (Traceable agent container): Defines the security settings for the main Traceable agent container, ensuring proper access control and process isolation.

    • mirroringSecurityContext: Configures security attributes for the container handling traffic mirroring, essential for monitoring network traffic securely.

    • grpcToHttpContainerSecurityContext: Specifies security settings for the gRPC-to-HTTP conversion container, ensuring safe handling of protocol translations.

    • extensionServiceSecurityContext: Applies to the extension service container, managing secure interactions with additional services or plugins.

    • ebpfSecurityContext: Tailored security settings for the eBPF container, crucial for safely running eBPF programs.

    • secretsInitSecurityContext: Configures security for the secrets initialization container, safeguarding sensitive information during setup.

Configuration Example

Here is a sample configuration for a container-level security context. This configuration is written in YAML, a human-readable data serialization format commonly used for Kubernetes configuration files. Each section defines security-related settings for different containers:

  • useCustomSecurityContext: Enables the use of custom security contexts for containers.

  • commonContainerSecurityContext: Specifies shared security settings applied to all containers.

  • securityContext: Defines settings specific to the main Traceable agent container.

  • mirroringSecurityContext, grpcToHttpContainerSecurityContext, etc.: Provide container-specific security configurations.

Below is the YAML configuration: 

# Container securityContext.
useCustomSecurityContext: true

# Common container security context.
commonContainerSecurityContext:
  runAsUser: 1001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    add: ["NET_ADMIN"]
    drop: ["ALL"]

# Specific container security contexts.
securityContext:
  runAsUser: 1000
mirroringSecurityContext:
  runAsUser: 1002
grpcToHttpContainerSecurityContext:
  runAsUser: 1003

Key Attributes

  • runAsUser: Specifies the user ID for container processes.

  • allowPrivilegeEscalation: Determines whether the container can gain additional privileges.

  • readOnlyRootFilesystem: Enforces a read-only file system to prevent unauthorized writes.

  • capabilities: Adds or drops Linux capabilities for enhanced security.

Pro-tip

Use commonContainerSecurityContext to define shared security settings for simplicity and consistency. For example, if multiple containers in your pod need the same security configurations, you can define them once under commonContainerSecurityContext. This avoids duplication and ensures consistency across containers.

Here’s an example of how to use commonContainerSecurityContext effectively: 

# Common container security context applied to all containers.
commonContainerSecurityContext:
  runAsUser: 2000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    add: ["NET_ADMIN"]
    drop: ["ALL"]

# Specific container security contexts.
securityContext:
  runAsUser: 3000
mirroringSecurityContext:
  runAsUser: 3001
grpcToHttpContainerSecurityContext:
  runAsUser: 3002

In this example:

  • The commonContainerSecurityContext ensures that all containers have a baseline security configuration (e.g., non-root user, read-only filesystem, limited capabilities).

  • Specific containers, such as securityContext or grpcToHttpContainerSecurityContext, override only the attributes they need to change, inheriting the rest from the common context.

This approach keeps configurations manageable and reduces the risk of misconfiguration.

Best Practices for Security Contexts

  1. Avoid Running as Root: Set runAsUser to a non-root user ID to minimize security risks.

  2. Use Read-Only File Systems: Enable readOnlyRootFilesystem to protect against malicious writes.

  3. Drop Unnecessary Capabilities: Use the capabilities field to limit the container's access to privileged operations.

  4. Audit and Test: Regularly review and test your security settings to ensure compliance with organizational and regulatory standards.