Skip to content

Kubernetes API Approach Security Risk Analysis

This document provides a detailed security risk analysis of the Kubernetes API approach to container scanning, which uses the train-k8s-container transport plugin.

Security Model

The Kubernetes API approach uses the Kubernetes API server to execute commands within target containers.

Security Characteristics

Security Factor Rating Description
Required Privileges 🟢 Low Only requires pod "get", "list", and "exec" permissions
Attack Surface 🟢 Minimal Uses standard Kubernetes API only
Credential Exposure 🟢 Minimal Uses short-lived service account tokens
Isolation Level 🟢 High Preserves container isolation
Persistence Risk 🟢 None Stateless operation with no persistent components

Detailed Risk Assessment

Authentication and Authorization Risks

Risk Likelihood Impact Mitigation
Token leakage Low Medium Short-lived tokens, minimal permissions
Excessive permissions Low Medium Least privilege RBAC implementation
Authentication bypass Very Low High Standard Kubernetes authentication mechanisms

Operational Risks

Risk Likelihood Impact Mitigation
Command injection Low Medium Input validation, limited command execution
Resource exhaustion Low Low Resource limits on scanner activities
Scan disruption Medium Low Retry mechanisms, graceful error handling

Container Risks

Risk Likelihood Impact Mitigation
Container compromise Very Low Medium Restricted command execution, minimal privileges
Container interference Low Medium No modification of container state
Data exfiltration Low Medium Limited access to container contents

Risk Comparison

When compared to other scanning approaches, the Kubernetes API approach presents:

  • Lower risk than the Debug Container approach in terms of required privileges and attack surface
  • Lower risk than the Sidecar Container approach in terms of isolation preservation and container security principles

Risk Scenarios and Mitigations

Scenario 1: Token Compromise

Risk: An attacker obtains a scanner's service account token.

Mitigations:

  1. Token is short-lived (default 15-minute expiration)
  2. Token has minimal permissions (only specific pods)
  3. Token can only execute commands, not modify resources
  4. Comprehensive audit logging of all API operations

Residual Risk: Low - Even with a compromised token, an attacker's capabilities are severely limited in both scope and time.

Scenario 2: Scanner Process Compromise

Risk: The scanner process itself is compromised during operation.

Mitigations:

  1. Scanner has minimal Kubernetes permissions
  2. Scanner operates for a limited duration
  3. No persistent access to cluster
  4. No ability to modify cluster resources

Residual Risk: Low to Medium - A compromised scanner has limited ability to affect the broader cluster.

Scenario 3: Command Injection

Risk: Malicious input causes unexpected command execution.

Mitigations:

  1. Input validation for all parameters
  2. Restricted command execution capabilities
  3. Non-privileged command execution
  4. Container isolation remains intact

Residual Risk: Low - Command execution is constrained by container context and permissions.

Enterprise Security Considerations

For enterprise deployments:

  1. Audit Logging: Enable comprehensive Kubernetes audit logging
  2. Token Management: Implement proper token lifecycle management
  3. Scanner Verification: Verify scanner container integrity before deployment
  4. Network Policies: Implement network policies to restrict scanner communication
  5. Monitoring: Monitor for unexpected scanning operations

Conclusion

The Kubernetes API approach presents the lowest overall security risk profile among the available container scanning approaches. Its use of standard Kubernetes interfaces, minimal permissions, and preservation of container isolation principles makes it the preferred choice for security-conscious environments.

The approach maintains strong security boundaries while still providing effective container scanning capabilities. Its primary limitation is the requirement for containers to have shell access, which is addressed by alternative approaches for distroless containers.