ADR-0001: Display Secrets in Plain Text in SPIKE Pilot Admin CLI
- Status: accepted
- Date: 2024-10-28
- Tags: Security, Operations, Convenience
Context and Problem Statement
The SPIKE Pilot admin interface needs to provide access to secrets for administrative purposes. We need to determine the most secure and practical way to display these secrets while maintaining system security and operational efficiency.
Decision Drivers
- Security of sensitive information
- Operational efficiency for administrators
- Prevention of workarounds that could increase attack surface
- Auditability of secret access
- User experience for administrators
Considered Options
- Display secrets in plain text
- Display only encrypted secrets
- Never display secrets through admin interface
Decision
Display secrets in plain text in the SPIKE Pilot admin CLI, while providing additional interfaces to view only keys or metadata when full secret values aren’t needed.
Rationale
- Administrators who can write and delete secrets should logically be able to view them.
- Encrypting displayed secrets provides false security since:
- Admins with access likely have decryption keys anyway
- It only adds inconvenience without meaningful security benefits
- Preventing secret viewing would likely lead to:
- Creation of throwaway secret consumer apps
- Increased attack surface through workarounds
- Existing security measures provide adequate protection:
- mTLS for secret fetching
- Short-lived sessions
- Audit logging through SPIKE Nexus
- Authentication and authorization checks
Consequences
Positive
- Simplified admin operations
- Reduced likelihood of workarounds
- Clear audit trail of secret access
- Consistent with principle of least surprise
Negative
- Potential for secrets to appear in logs or command history
- Increased responsibility on admin access control
Implementation Notes
- Implement separate interfaces for:
- Full secret display
- Keys-only view
- Metadata-only view
- Ensure proper audit logging of all secret access
- Document proper terminal/session management for admins
- 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