Security Components¶
This document details the security-focused components of the Kubernetes CINC Secure Scanner architecture.
Service Accounts¶
Service accounts provide identity management for secure scanner access.
- Purpose: Establish a secure identity for the scanner within Kubernetes
- Features:
- Temporary/ephemeral accounts for scanning operations
- Limited lifespan to reduce potential attack surface
- Namespace-specific isolation
- No permanent elevated privileges
RBAC Rules¶
RBAC (Role-Based Access Control) rules enforce least-privilege access for scanning operations.
- Purpose: Restrict scanner access to only what is necessary
- Features:
- Granular permission control
- Namespace-specific permissions
- Time-limited access
- Resource-specific limitations
- Label-based selection for targeted scanning
Security Token Management¶
Security token management provides controlled access to Kubernetes resources.
- Purpose: Secure authentication for scanning operations
- Features:
- Short-lived token generation
- Automatic token expiration
- No persistent credential storage
- Rotation mechanisms for long-running scans
Kubeconfig Security¶
Kubeconfig security ensures that Kubernetes configuration is properly secured.
- Purpose: Secure storage and management of Kubernetes access configurations
- Features:
- Temporary kubeconfig generation
- Restricted permissions
- No shared kubeconfig files
- Context-specific configurations
Secure Plugin Configuration¶
Secure plugin configuration ensures that the transport plugin operates securely.
- Purpose: Configure the transport plugin with secure defaults
- Features:
- No privilege escalation
- Restricted filesystem access
- Command execution limitations
- Secure parameter handling
Security Component Interaction Diagram¶
flowchart TD
A[Start Scan Process] --> B[Create Temporary Service Account]
B --> C[Apply Least-Privilege RBAC]
C --> D[Generate Short-lived Token]
D --> E[Create Restricted Kubeconfig]
E --> F[Configure Transport Plugin Security]
F --> G[Execute Scanner with Security Constraints]
G --> H[Process Results Securely]
H --> I[Clean Up Security Resources]
I --> J[End Scan Process]
style A fill:#505050,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
style B fill:#4C366B,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
style C fill:#4C366B,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
style D fill:#4C366B,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
style E fill:#4C366B,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
style F fill:#217645,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
style G fill:#217645,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
style H fill:#217645,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
style I fill:#505050,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
style J fill:#505050,stroke:#FFFFFF,stroke-width:2px,color:#FFFFFF
Security Component Design Principles¶
The security components adhere to the following design principles:
- Least Privilege: Components only have access to the resources they need
- Defense in Depth: Multiple security layers protect the system
- Ephemeral Access: Temporary access reduces attack surface
- Audit Trail: Security operations are logged for accountability
- Isolation: Components are isolated to prevent lateral movement
- Clean Up: Security resources are reliably removed after use
Security Component Configuration¶
For detailed information about configuring security components, see: