browser-vault-gui/KV_V2_ENFORCEMENT.md
2025-10-20 19:34:11 +02:00

260 lines
7.6 KiB
Markdown

# KV v2 Enforcement - Simplification Complete
## ✅ All Changes Implemented
The application now **enforces KV v2** throughout, removing the complexity of supporting both KV v1 and v2. This simplifies the codebase and UI while focusing on the modern Vault standard.
## Changes Made
### 1. 🗑️ Removed KV Version Selection from UI
**ServerSelector.vue**:
- ✅ Removed KV version dropdown from "Add Server" form
- ✅ Removed `kvVersion` from `newServer` state
- ✅ Updated server cards to show static "KV v2" badge
- ✅ Simplified form validation and submission
**Before**:
```vue
<select v-model="newServer.kvVersion">
<option :value="2">KV v2 (recommended)</option>
<option :value="1">KV v1 (legacy)</option>
</select>
```
**After**:
```vue
<!-- KV v2 is enforced - no version selection needed -->
```
### 2. 🔧 Updated Type Definitions
**types.ts**:
- ✅ Removed `kvVersion?: 1 | 2` from `VaultServer` interface
- ✅ Added comment explaining KV v2 enforcement
- ✅ Simplified server object structure
**Before**:
```typescript
export interface VaultServer {
id: string;
name: string;
url: string;
description?: string;
kvVersion?: 1 | 2; // KV secret engine version (default: 2)
savedCredentials?: VaultCredentials;
}
```
**After**:
```typescript
export interface VaultServer {
id: string;
name: string;
url: string;
description?: string;
// KV v2 is enforced - no version selection needed
savedCredentials?: VaultCredentials;
}
```
### 3. ⚙️ Simplified VaultApi Service
**vaultApi.ts**:
- ✅ Removed `kvVersion` parameter from `createClient()`
- ✅ Hard-coded `kvVersion: 2` in VaultClient constructor
- ✅ Updated all method calls to remove version parameter
- ✅ Simplified `searchAllMounts()` logic
**Before**:
```typescript
private createClient(
server: VaultServer,
credentials: VaultCredentials,
kvVersion: 1 | 2 = 2
): VaultClient {
return new VaultClient({
server,
credentials,
timeout: 30000,
retries: 2,
kvVersion, // KV v2 by default (most common)
});
}
```
**After**:
```typescript
private createClient(
server: VaultServer,
credentials: VaultCredentials
): VaultClient {
return new VaultClient({
server,
credentials,
timeout: 30000,
retries: 2,
kvVersion: 2, // KV v2 is enforced
});
}
```
### 4. 📋 Updated Dashboard Display
**Dashboard.vue**:
- ✅ Mount point selector shows static "v2" for all mounts
- ✅ Removed conditional version display logic
- ✅ Simplified mount point rendering
**Before**:
```vue
{{ mount.path }}/ ({{ mount.type }} v{{ mount.options?.version || '1' }})
```
**After**:
```vue
{{ mount.path }}/ ({{ mount.type }} v2)
```
### 5. 🔐 Simplified SecretModal
**SecretModal.vue**:
- ✅ Always loads metadata and versions (no KV version check)
- ✅ Removed conditional metadata loading logic
- ✅ Updated footer text to reflect KV v2 enforcement
- ✅ Simplified error messages
**Before**:
```typescript
// Try to load metadata and versions (KV v2 only)
if (props.server.kvVersion === 2) {
await loadMetadataAndVersions();
}
```
**After**:
```typescript
// Load metadata and versions (KV v2 enforced)
await loadMetadataAndVersions();
```
## Benefits of KV v2 Enforcement
### 🎯 Simplified User Experience
- **No confusing choices** - users don't need to know about KV versions
- **Consistent behavior** - all features work the same way
- **Modern defaults** - KV v2 is the current Vault standard
- **Reduced cognitive load** - fewer options to understand
### 🔧 Cleaner Codebase
- **Less complexity** - no conditional logic for versions
- **Fewer parameters** - simplified method signatures
- **Better maintainability** - single code path to maintain
- **Reduced testing surface** - fewer edge cases
### 📊 Enhanced Features
- **Always available metadata** - version history, timestamps, etc.
- **Consistent API paths** - `/data/` and `/metadata/` endpoints
- **Better secret management** - soft deletes, version control
- **Audit capabilities** - full version history tracking
### 🚀 Performance Benefits
- **No version detection** - faster mount point processing
- **Optimized API calls** - direct KV v2 endpoint usage
- **Simplified caching** - consistent cache key generation
- **Reduced overhead** - no version-specific logic
## Technical Implementation
### API Endpoint Usage
All secret operations now use KV v2 endpoints:
- **List**: `/v1/{mount}/metadata/{path}?list=true`
- **Read**: `/v1/{mount}/data/{path}`
- **Write**: `/v1/{mount}/data/{path}`
- **Delete**: `/v1/{mount}/data/{path}`
- **Metadata**: `/v1/{mount}/metadata/{path}`
### Mount Point Detection
Mount points are detected via `/v1/sys/internal/ui/mounts` and filtered for:
- `type === 'kv'` (KV secret engines)
- `type === 'generic'` (legacy KV engines)
All detected KV mounts are treated as v2.
### Secret Modal Features
With KV v2 enforcement, the SecretModal always provides:
- **Current secret data** with JSON formatting
- **Complete metadata** including versions, timestamps
- **Version history** with ability to view any version
- **Audit trail** showing creation/modification times
## Migration Notes
### For Existing Users
- **No data loss** - existing server configurations preserved
- **Automatic upgrade** - all servers now treated as KV v2
- **Enhanced features** - metadata and versions now always available
- **Simplified interface** - no version selection needed
### For Vault Administrators
- **KV v2 required** - ensure all secret engines are KV v2
- **Migration path** - upgrade KV v1 engines to v2 if needed
- **Feature compatibility** - all advanced features require KV v2
### Vault KV v1 to v2 Migration
If you have KV v1 engines, upgrade them:
```bash
# Enable KV v2 engine
vault secrets enable -path=secret -version=2 kv
# Migrate data from v1 to v2 (manual process)
# Note: This requires custom scripting as there's no direct migration
```
## Error Handling
### KV v1 Compatibility
If the application encounters a KV v1 engine:
- **Metadata loading** will fail gracefully
- **Basic secret reading** will still work
- **Version history** will be unavailable
- **User feedback** indicates KV v2 features missing
### Graceful Degradation
The application handles KV v1 engines by:
- Showing error messages for metadata operations
- Continuing to function for basic secret operations
- Providing clear feedback about missing features
- Suggesting KV v2 upgrade in error messages
## Future Considerations
### Potential Enhancements
With KV v2 enforcement, future features could include:
- **Secret versioning UI** - visual diff between versions
- **Rollback functionality** - restore previous versions
- **Metadata editing** - custom metadata management
- **Deletion policies** - configure auto-deletion rules
- **Secret templates** - predefined secret structures
### Advanced KV v2 Features
Could be implemented:
- **Check-and-set operations** - prevent concurrent modifications
- **Secret patching** - partial updates to secrets
- **Metadata-only operations** - manage metadata without reading secrets
- **Bulk operations** - batch secret management
## Conclusion
**KV v2 enforcement successfully implemented**:
1. **🗑️ Removed version selection** - simplified UI
2. **🔧 Updated all services** - consistent KV v2 usage
3. **📋 Enhanced features** - metadata always available
4. **🚀 Improved performance** - optimized for single version
The application now provides a **streamlined, modern experience** focused on KV v2's advanced capabilities while maintaining **backward compatibility** through graceful degradation.
**Key Achievement**: Transformed from a dual-version system to a **focused, feature-rich KV v2 application** with enhanced metadata, versioning, and audit capabilities.