feat: migrate from agenix to agenix-rekey

[johnae]

Switch secrets management from agenix (single secrets.nix) to agenix-rekey with per-host rekeyed secrets. Each host declares its own hostPubkey and secrets are re-encrypted per-host at rekey time.

• Add agenix-rekey flake input and per-system module
• Add per-host age.rekey config (hostPubkey, storageMode, localStorageDir)
• Use YubiKey master identities with extraEncryptionPubkeys for multi-key support
• Add rekeyed secrets for all hosts and home-manager configs
• Extract admin users into dedicated module
• Remove old secrets.nix and unused microvm configurations
• Update flake.lock

[claude]

Claude finished @johnae's task —— View job

---

PR Review: Migrate from agenix to agenix-rekey

I've completed my review of this significant migration from agenix to agenix-rekey for secrets management. Here's my comprehensive feedback:

Todo List

• Analyze the migration strategy and overall architecture
• Review security implications of the new secrets management
• Check code quality and best practices
• Identify potential bugs or issues
• Assess performance considerations
• Evaluate test coverage

Overall Assessment

This is a well-executed migration that significantly improves the security posture of the secrets management system by implementing per-host secret rekeying.

✅ Strengths

1. Security Improvements

• Per-host encryption: Each host now has its own public key and secrets are re-encrypted specifically for that host (e.g., configurations/nixos/x86_64-linux/antares.nix:8-11)
• YubiKey integration: Uses YubiKey master identities with extra encryption pubkeys for multi-key support, enhancing physical security
• Proper secret isolation: Secrets are now organized by host and home-manager configurations in separate directories
• Local storage mode: Uses local storage for rekeyed secrets, reducing attack surface

2. Code Quality & Architecture

• Clean modularization: Extracted admin users into dedicated module (users/admin-users.nix)
• Consistent configuration: All hosts follow the same pattern for age.rekey configuration
• Proper separation: Home-manager secrets are properly separated with -hm suffix
• Good naming convention: Hash-prefixed secret files prevent naming conflicts

3. Maintenance Benefits

• Removed dead code: Cleaned up 10+ unused microvm configurations
• Simplified structure: More maintainable per-host secret management vs single secrets.nix file

⚠️ Areas of Concern

1. Potential Bugs/Issues

• Hardcoded SSH keys: Some configs have hardcoded SSH public keys in authorized_keys (e.g., configurations/nixos/x86_64-linux/almach.nix:191)
• Missing validation: No apparent validation that hostPubkey matches the actual host's SSH key
• Path construction: Using string concatenation for paths (localStorageDir = ../../../secrets/rekeyed + "/${hostName}") could be fragile

2. Security Considerations

• Master identity exposure: The master identity public keys are exposed in secrets/identity.pub - ensure these are properly protected
• No secret rotation: While rekeying is implemented, there's no apparent automatic secret rotation mechanism
• Shared secrets: Some secrets appear to be shared across hosts (e.g., k3s-token, cluster-secrets) which could be a single point of failure

3. Performance Considerations

• Build-time overhead: Rekeying happens at build time for each host, which could slow down deployments with many hosts
• Storage duplication: Each host stores its own copy of rekeyed secrets, increasing storage requirements

4. Test Coverage

• No visible tests: The PR doesn't include any tests for the migration or the new rekeying functionality
• Missing validation: No automated checks to ensure secrets are correctly rekeyed for each host
• No rollback plan: No apparent rollback mechanism if rekeying fails

🔧 Recommendations

1. Add validation: Implement checks to ensure hostPubkey matches the actual host's SSH host key
2. Use proper path functions: Replace string concatenation with Nix path manipulation functions
3. Add tests: Create integration tests for the rekeying process
4. Document the process: Add documentation for how to add new secrets and hosts
5. Implement secret rotation: Consider adding automatic secret rotation capabilities
6. Add monitoring: Implement checks to ensure secrets are accessible and properly encrypted
7. Consider using age.rekey.hostPubkey = config.services.openssh.hostKeys.0.publicKey instead of hardcoding

📝 Best Practices Implemented

• ✅ Proper use of flake inputs for agenix-rekey
• ✅ Consistent module structure across all configurations
• ✅ Good separation between system and home-manager secrets
• ✅ Use of YubiKey for enhanced security
• ✅ Clean removal of deprecated configurations

Conclusion

This migration is a significant security improvement and is generally well-implemented. The main concerns are around testing, validation, and documentation. The code quality is good, but adding automated tests and validation would make this production-ready.