ADR-0005: Use SPIFFE mTLS for Inter-Component Authentication and Communication
- Status: accepted
- Date: 2024-11-03
- Tags: Security, Networking, SPIFFE, SPIRE
Context
Our system requires secure communication between various components with:
- Strong mutual authentication
- Network-level security
- Identity management for services
- Automated certificate management
- Zero-trust security model
Current challenges in service-to-service authentication include:
- Managing service identities
- Certificate distribution and renewal
- Secure communication channels
- Identity verification between components
Decision
We will implement SPIFFE with mTLS for all inter-component communication and authentication:
-
Authentication Mechanism:
- Use SPIFFE SVIDs (SPIFFE Verifiable Identity Document) for component identification
- Implement mutual TLS (mTLS) for all service-to-service communication
-
Identity Management:
- Each component will be assigned a unique SPIFFE ID
- Components will authenticate using their SVIDs
-
Security Layer:
- Network security will be handled at the TLS layer using SPIFFE-issued certificates
- All communication will be encrypted using mTLS
Consequences
Positive
- Strong cryptographic identity for each workload
- Automated certificate management
- Zero-trust security model implementation
- Dynamic identity provisioning
- Reduced operational overhead for certificate management
- Platform-agnostic identity management
- Standardized authentication mechanism
- Automatic certificate rotation
- No shared secrets required
Negative
- Additional system complexity
- Need for SPIFFE infrastructure maintenance
- Performance overhead from TLS handshakes
- Need to manage SPIFFE deployment and updates
Implementation Requirements
Infrastructure
- Deploy SPIFFE/SPIRE server
- Configure workload attestation
- Set up certificate authority integration
Component Integration
- Implement SPIFFE workload API in all components
- Configure mTLS endpoints
- Implement SVID verification
Security Considerations
- Secure SPIFFE control plane
- Configure proper attestation policies
- Implement certificate rotation policies
- Monitor SVID lifecycle
Monitoring and Maintenance
- Monitor certificate expiration
- Track authentication failures
- Audit identity assignments
- Monitor SPIFFE infrastructure health
Recovery Procedures
Certificate Issues
- Automated SVID renewal
- Manual SVID regeneration procedures
- Fallback authentication methods
Infrastructure Issues
- SPIFFE server redundancy
- Backup attestation procedures
- Emergency access procedures
References
Notes
Regular security audits should verify the correct implementation of SPIFFE/mTLS configurations and assess the effectiveness of the authentication mechanisms.
- ADR-0021: SPIKE Keeper as a Stateless Shard Holder
- ADR-0020: Switch to Zola for Documentation System
- ADR-0019: Plugin-Based Storage Backend Architecture
- ADR-0018: Administrative Access to SPIKE
- ADR-0017: Synchronous Persistence for SPIKE Secrets Store
- ADR-0016: Memory-First Secrets Store
- ADR-0015: Use Singular Form for File and Package Naming
- ADR-0014: Maintaining SQLite as SPIKE’s Primary Storage Backend
- ADR-0013: S3-Compatible Storage as SPIKE’s Backing Store
- ADR-0012: HTTP Methods for SPIKE API
- ADR-0011: PostgreSQL as SPIKE’s Backing Store
- ADR-0010: Session Token Storage Strategy for SPIKE Nexus
- ADR-0009: Multi-Administrator Support System
- ADR-0008: Administrative Access Control System
- ADR-0007: Root Key Lifecycle and Management Strategy
- ADR-0006: Trust Boundary Definition and Security Assumptions
- ADR-0005: Use SPIFFE mTLS for Inter-Component Authentication and Communication
- ADR-0004: SPIKE Keeper Minimalist Design Approach
- ADR-0003: Root Key Management and Storage Strategy
- ADR-0002: Use Docsify for Documentation System
- ADR-0001: Display Secrets in Plain Text in SPIKE Pilot Admin CLI