-
Notifications
You must be signed in to change notification settings - Fork 261
Description
Description
Flipt v2 currently has two authentication storage scenarios that could benefit from secrets management integration:
- Static Tokens - Currently only defined in configuration files, making them hard to rotate and manage
- Session Storage - Currently supports memory and Redis backends for session data
With the new secrets management feature in v2 that supports external providers (File, Vault, and more coming), we should extend this capability to improve both authentication scenarios.
Motivation
This integration would provide several benefits:
- Unified Secret Management - Both static tokens and session data could leverage the same secret providers
- Enhanced Security - Leverage enterprise-grade secret management systems like HashiCorp Vault
- Better Token Lifecycle Management - Use Vault's TTL, rotation, and audit capabilities
- Dynamic Token Management - Create and manage static tokens via UI/API instead of only through config files
- Compliance - Meet regulatory requirements by storing tokens in approved secret management systems
Proposed Implementation
Part 1: Static Token Management
Currently, static tokens can only be defined in configuration files, which has limitations:
- Tokens are visible in config files
- Rotation requires config file changes and restarts
- No programmatic way to create/manage tokens
Solution A: Secret References in Config
This should already work via the secret references
Allow static tokens to use secret references:
authentication:
methods:
token:
enabled: true
tokens:
- credential: "{{ secret.vault.flipt/tokens/ci-token.value }}"
metadata:
name: "CI Pipeline Token"
- credential: "{{ secret.file.tokens/dev-token.value }}"
metadata:
name: "Development Token"
Solution B: Dynamic Token Management
When a secret store is configured, enable creating static tokens via UI/API:
authentication:
methods:
token:
enabled: true
storage:
type: secrets # Store dynamically created tokens in secrets
secrets:
provider: vault
path: flipt/static-tokens
This would enable:
- Creating tokens via UI with automatic storage in secret backend
- API endpoints for token management (create, list, revoke)
- Tokens never exposed in configuration files
Part 2: Session Storage Backend
Extend session storage to support secrets providers:
authentication:
required: true
session:
storage:
type: secrets # New storage type
secrets:
provider: vault # Use configured secrets provider
path: flipt/sessions # Base path for session storage
Implementation Details
1. Dynamic Token Management with Secrets Backend
authentication:
methods:
token:
enabled: true
# Tokens from config (backward compatible)
tokens:
- credential: "some-static-token"
metadata:
name: "Legacy Token"
# Dynamic token storage
storage:
type: secrets
secrets:
provider: vault
path: flipt/api-tokens
# Optional: auto-expire tokens using provider features
ttl: 90d
auto_rotate: true
2. Session Storage with Secrets
authentication:
required: true
session:
storage:
type: secrets
secrets:
provider: vault
path: flipt/sessions
# Provider-specific optimizations
cache:
enabled: true # Local cache for performance
ttl: 5m
Token Storage Format
Store authentication data as JSON in the secret value:
{
"id": "auth-id-123",
"method": "TOKEN",
"credential_hash": "sha256:abc123...", // Only store hash, not plaintext
"metadata": {
"name": "CI Token",
"description": "Token for CI/CD pipeline",
"created_by": "[email protected]"
},
"created_at": "2024-01-15T10:00:00Z",
"expires_at": "2024-12-31T23:59:59Z",
"last_used_at": "2024-01-20T15:30:00Z"
}
UI/API Enhancements
When secret storage is configured for tokens:
UI Features
- Token Management Page: Create, list, and revoke tokens
- Token Creation Dialog: Set name, description, expiration
- Token Display: Show token once on creation (never stored in plaintext)
API Endpoints
POST /api/v2/auth/tokens # Create new token
GET /api/v2/auth/tokens # List tokens (metadata only)
DELETE /api/v2/auth/tokens/{id} # Revoke token
Implementation Tasks
Phase 1: Secret References for Static Tokens
- Update documentation with examples
Phase 2: Session Storage Backend
- Add
secrets
storage type to session configuration - Implement
SecretsStore
for session storage - Add caching layer for performance
- Handle cleanup/expiration for stored sessions
Phase 3: Dynamic Token Management
- Add
storage
configuration to token authentication method - Implement token CRUD operations with secrets backend
- Create UI components for token management
- Add API endpoints for token operations
Testing & Documentation
- Unit tests for secret reference resolution
- Integration tests with File and Vault providers
- Performance benchmarks for session storage
- Migration guide from static config to dynamic tokens
- Update authentication documentation
Backward Compatibility
- Existing static tokens in config continue to work
- Current memory and Redis session storage unchanged
- Default behavior remains the same
- Gradual migration path for existing deployments
Security Considerations
- Never store plaintext tokens, only hashes
- Token values shown only once on creation
- Support provider-specific security features (Vault policies, etc.)
Questions for Discussion
- Should we support mixing static (config) and dynamic (secret-stored) tokens?
- Can we support secrets rotation?