Mitigation Strategy: Configure Secure Seccomp Profiles
-
Description:
- Analyze Application System Calls: Understand the system calls required by your containerized applications.
- Create Custom Seccomp Profiles: Develop custom seccomp profiles (in JSON format) that precisely define allowed system calls, minimizing the allowed set to only what's necessary.
- Apply Seccomp Profiles to Containers in containerd: Configure containerd to enforce these custom seccomp profiles when launching containers. This is typically done through containerd's runtime configuration or via orchestration platforms that interact with containerd.
- Test and Refine Profiles: Thoroughly test applications with seccomp profiles applied by containerd to ensure functionality and refine profiles as needed.
-
Threats Mitigated:
- Container Escape Vulnerabilities (Critical Severity): Seccomp, enforced by containerd, significantly limits the syscalls available to a container, hindering exploitation of escape vulnerabilities.
- Privilege Escalation within Containers (High Severity): Restricting syscalls via containerd-applied seccomp profiles reduces the ability to escalate privileges inside a container.
-
Impact:
- Container Escape Vulnerabilities: High risk reduction. Makes container escapes much harder to exploit effectively due to syscall restrictions enforced by containerd.
- Privilege Escalation within Containers: High risk reduction. Limits the attacker's ability to gain root privileges within the container by restricting syscalls through containerd.
-
Currently Implemented: Partially implemented. Default seccomp profiles are used by containerd, but custom profiles tailored to specific applications and actively configured within containerd are not widely deployed.
-
Missing Implementation:
- Analysis of application syscall requirements for all containerized applications to inform custom profile creation.
- Creation of custom seccomp profiles for each application to be enforced by containerd.
- Systematic deployment of custom seccomp profiles within containerd's configuration.
- Ongoing testing and refinement of seccomp profiles applied by containerd.
Mitigation Strategy: Utilize AppArmor or SELinux for Mandatory Access Control (MAC) via containerd
-
Description:
- Choose MAC System (Host Level): Select AppArmor or SELinux on the host OS.
- Develop MAC Profiles: Create MAC profiles that define access control policies for containers, restricting access to host resources.
- Apply MAC Profiles to Containers through containerd: Configure containerd to apply these MAC profiles to containers during runtime. This is achieved through containerd's runtime configuration or orchestration platforms that instruct containerd to use specific profiles.
- Test and Refine Profiles: Test applications with MAC profiles enforced by containerd and refine profiles based on application needs and security requirements.
-
Threats Mitigated:
- Container Escape Vulnerabilities (Critical Severity): MAC systems, when integrated with containerd, provide an extra layer of defense against escapes by restricting host resource access even after an escape.
- Lateral Movement from Compromised Containers (High Severity): MAC profiles enforced by containerd can limit a compromised container's ability to access other containers or host resources, hindering lateral movement.
- Data Breaches from Container Compromise (High Severity): MAC, when configured via containerd, can restrict container access to sensitive host data, reducing the impact of compromise.
-
Impact:
- Container Escape Vulnerabilities: High risk reduction. Adds a significant defense layer against successful escapes when enforced by containerd.
- Lateral Movement from Compromised Containers: High risk reduction. Limits attacker spread within the environment through containerd-enforced policies.
- Data Breaches from Container Compromise: Medium to High risk reduction, depending on MAC profile restrictiveness and containerd's enforcement.
-
Currently Implemented: Not implemented. AppArmor or SELinux profiles are not currently actively used for containers through containerd in our project.
-
Missing Implementation:
- Developing MAC profiles for containerized applications to be used with containerd.
- Integrating MAC profile enforcement within containerd's configuration.
- Testing and refining MAC profiles enforced by containerd.
Mitigation Strategy: Restrict Container Capabilities via containerd
-
Description:
- Analyze Required Capabilities: Determine the minimum Linux capabilities needed for each containerized application.
- Drop Unnecessary Capabilities in containerd configuration: Configure containerd to drop all default capabilities and then selectively add back only the essential ones for each container. This is done through containerd's runtime configuration or orchestration platforms instructing containerd.
- Avoid
CAP_SYS_ADMIN
: Specifically ensureCAP_SYS_ADMIN
is dropped by containerd unless absolutely necessary and carefully justified. - Document Required Capabilities: Document the specific capabilities required and configured in containerd for each application.
-
Threats Mitigated:
- Privilege Escalation within Containers (High Severity): Excessive capabilities, if not restricted by containerd, allow privileged operations, potentially leading to root access or host compromise.
- Container Escape Vulnerabilities (Critical Severity): Certain capabilities can be exploited for escapes. Containerd's capability restriction reduces the attack surface.
-
Impact:
- Privilege Escalation within Containers: High risk reduction. Limits attacker ability to gain elevated privileges within containers by containerd's capability control.
- Container Escape Vulnerabilities: Medium to High risk reduction, depending on capabilities dropped and exploit type, through containerd's enforcement.
-
Currently Implemented: Partially implemented. We generally avoid granting
CAP_SYS_ADMIN
, but explicit dropping of capabilities via containerd configuration and detailed analysis are not consistently applied. -
Missing Implementation:
- Systematic analysis of required capabilities for all applications to inform containerd configuration.
- Explicitly dropping unnecessary capabilities in containerd's configuration.
- Enforcement of capability restrictions through containerd runtime policies.
- Documentation of capabilities configured in containerd for each application.
Mitigation Strategy: Secure containerd's gRPC API
-
Description:
- Disable API if Unnecessary in containerd configuration: If the gRPC API is not needed for external access, disable it in containerd's configuration to minimize attack surface.
- Implement Authentication and Authorization for containerd API: If the API is required, enable strong authentication and authorization within containerd's API configuration. Use methods like TLS client certificates (mTLS) or API keys.
- Use TLS Encryption for containerd API: Always enable and enforce TLS encryption for all communication with containerd's gRPC API in containerd's configuration.
- Restrict Network Access to containerd API: Use network firewalls or policies to restrict network access to containerd's gRPC API to only authorized networks or IP addresses. This is a network-level control around containerd.
- Regularly Audit API Access logs from containerd: Enable and regularly review containerd's API access logs to detect unauthorized or suspicious activity.
-
Threats Mitigated:
- Unauthorized Container Management (High Severity): Unsecured containerd gRPC API can allow unauthorized control over containers, leading to compromise, data breaches, and DoS.
- Data Exposure via API (Medium Severity): Unencrypted containerd API communication can expose sensitive container data to eavesdropping.
-
Impact:
- Unauthorized Container Management: High risk reduction. Prevents unauthorized control over containers through containerd's API security.
- Data Exposure via API: Medium risk reduction. Protects sensitive data transmitted via containerd's API through encryption.
-
Currently Implemented: Partially implemented. TLS encryption is used for the gRPC API, but strong authentication and authorization within containerd itself are not fully enforced. Network access restriction is basic.
-
Missing Implementation:
- Implementing strong authentication and authorization within containerd's gRPC API configuration (e.g., mTLS).
- Strictly restricting network access to the API using firewalls and network policies around containerd.
- Regular auditing of containerd's gRPC API access logs.
Mitigation Strategy: Audit containerd Events and Logs
-
Description:
- Enable containerd Event Stream: Ensure containerd's event stream is enabled to capture container lifecycle events and errors generated by containerd.
- Configure Logging in containerd: Configure containerd to generate detailed logs, including API requests, errors, and security events within containerd's logging configuration.
- Centralize Logs: Integrate containerd logs and events with a centralized logging system for analysis and alerting. This is an external system consuming containerd's output.
- Set Up Alerts: Configure alerts in the monitoring system to notify security teams of suspicious events or errors from containerd logs.
- Regularly Review Logs: Regularly review containerd logs and events to identify security incidents, misconfigurations, or performance issues related to containerd operations.
-
Threats Mitigated:
- Delayed Incident Detection (Medium Severity): Lack of proper logging from containerd delays detection of security incidents related to container runtime operations.
- Insufficient Forensic Information (Medium Severity): Inadequate logging from containerd limits forensic data for investigating container runtime security incidents.
-
Impact:
- Delayed Incident Detection: Medium risk reduction. Enables faster detection of security incidents related to containerd.
- Insufficient Forensic Information: Medium risk reduction. Improves incident investigation and response capabilities for container runtime issues.
-
Currently Implemented: Partially implemented. Containerd logs are collected, but event streams are not fully utilized for security monitoring, and alerting based on containerd logs is not comprehensive.
-
Missing Implementation:
- Full utilization of containerd event streams for security monitoring.
- Comprehensive alerting based on containerd logs and events.
- Regular review and analysis of containerd logs specifically for security purposes.
Mitigation Strategy: Keep containerd and its Dependencies Updated
-
Description:
- Establish Update Schedule for containerd: Define a regular schedule for updating containerd and its direct dependencies (like
runc
). - Monitor Security Advisories for containerd: Subscribe to security advisories and release notes specifically for containerd and related projects.
- Automate Update Process for containerd: Automate the update process for containerd and its dependencies on container hosts.
- Test Updates in Staging: Thoroughly test containerd updates in a staging environment before production deployment.
-
Threats Mitigated:
- Exploitation of Known containerd/runc Vulnerabilities (Critical Severity): Unpatched vulnerabilities in containerd or
runc
can be directly exploited for container escapes, host compromise, and privilege escalation.
- Exploitation of Known containerd/runc Vulnerabilities (Critical Severity): Unpatched vulnerabilities in containerd or
-
Impact:
- Exploitation of Known containerd/runc Vulnerabilities: High risk reduction. Eliminates known vulnerabilities in containerd and
runc
by applying updates.
- Exploitation of Known containerd/runc Vulnerabilities: High risk reduction. Eliminates known vulnerabilities in containerd and
-
Currently Implemented: Partially implemented. We have a system for OS package updates, but containerd updates are not always prioritized and may lag.
-
Missing Implementation:
- Formalized update schedule specifically for containerd and its dependencies.
- Automated monitoring of security advisories specifically for containerd.
- Dedicated testing process for containerd updates before production.
- Establish Update Schedule for containerd: Define a regular schedule for updating containerd and its direct dependencies (like
Mitigation Strategy: Resource Limits and Quotas Enforced by containerd
-
Description:
- Define Resource Limits: Determine appropriate resource limits (CPU, memory, storage, network) for each container based on application needs.
- Enforce Resource Limits in containerd: Configure containerd to enforce these resource limits using cgroups and other resource management features available within containerd.
- Set Quotas via containerd: Implement quotas for storage and other resources using containerd's resource management capabilities to prevent resource exhaustion.
- Monitor Resource Usage: Monitor container resource usage to detect containers exceeding limits or showing unusual patterns. This monitoring is external to containerd but observes its effects.
-
Threats Mitigated:
- Denial of Service (DoS) via Resource Exhaustion (High Severity): Runaway or malicious containers can exhaust resources, causing DoS. Containerd-enforced limits prevent this.
- Resource Starvation (Medium Severity): One container consuming excessive resources can starve others. Containerd's limits ensure fair resource allocation.
-
Impact:
- Denial of Service (DoS) via Resource Exhaustion: High risk reduction. Containerd-enforced limits effectively prevent resource exhaustion DoS.
- Resource Starvation: High risk reduction. Containerd's resource management ensures fair allocation and prevents starvation.
-
Currently Implemented: Partially implemented. Resource limits are sometimes defined, but consistent enforcement via containerd configuration and quotas are not widely used.
-
Missing Implementation:
- Standardized definition and enforcement of resource limits through containerd configuration for all containers.
- Implementation of resource quotas using containerd's features.
- Automated monitoring and alerting for containers exceeding resource limits enforced by containerd.