Commit graph

3 commits

Author SHA1 Message Date
Pieter
071ed083f7 feat: Implement per-client SSH key isolation
Resolves #14

Each client now gets a dedicated SSH key pair, ensuring that compromise
of one client server does not grant access to other client servers.

## Changes

### Infrastructure (OpenTofu)
- Replace shared `hcloud_ssh_key.default` with per-client `hcloud_ssh_key.client`
- Each client key read from `keys/ssh/<client_name>.pub`
- Server recreated with new key (dev server only, acceptable downtime)

### Key Management
- Created `keys/ssh/` directory for SSH keys
- Added `.gitignore` to protect private keys from git
- Generated ED25519 key pair for dev client
- Private key gitignored, public key committed

### Scripts
- **`scripts/generate-client-keys.sh`** - Generate SSH key pairs for clients
- Updated `scripts/deploy-client.sh` to check for client SSH key

### Documentation
- **`docs/ssh-key-management.md`** - Complete SSH key management guide
- **`keys/ssh/README.md`** - Quick reference for SSH keys directory

### Configuration
- Removed `ssh_public_key` variable from `variables.tf`
- Updated `terraform.tfvars` to remove shared SSH key reference
- Updated `terraform.tfvars.example` with new key generation instructions

## Security Improvements

 Client isolation: Each client has dedicated SSH key
 Granular rotation: Rotate keys per-client without affecting others
 Defense in depth: Minimize blast radius of key compromise
 Proper key storage: Private keys gitignored, backups documented

## Testing

-  Generated new SSH key for dev client
-  Applied OpenTofu changes (server recreated)
-  Tested SSH access: `ssh -i keys/ssh/dev root@78.47.191.38`
-  Verified key isolation: Old shared key removed from Hetzner

## Migration Notes

For existing clients:
1. Generate key: `./scripts/generate-client-keys.sh <client>`
2. Apply OpenTofu: `cd tofu && tofu apply` (will recreate server)
3. Deploy: `./scripts/deploy-client.sh <client>`

For new clients:
1. Generate key first
2. Deploy as normal

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2026-01-17 19:50:30 +01:00
Pieter van Boheemen
054e0e1e87
Deploy Zitadel identity provider with DNS automation (#3) (#8)
This commit implements a complete Zitadel identity provider deployment
with automated DNS management using vrije.cloud domain.

## Infrastructure Changes

### DNS Management
- Migrated from deprecated hetznerdns provider to modern hcloud provider v1.57+
- Automated DNS record creation for client subdomains (test.vrije.cloud)
- Automated wildcard DNS for service subdomains (*.test.vrije.cloud)
- Supports both IPv4 (A) and IPv6 (AAAA) records

### Zitadel Deployment
- Added complete Zitadel role with PostgreSQL 16 database
- Configured Zitadel v2.63.7 with proper external domain settings
- Implemented first instance setup with admin user creation
- Set up database connection with proper user and admin credentials
- Configured email verification bypass for first admin user

### Traefik Updates
- Upgraded from v3.0 to v3.2 for better Docker API compatibility
- Added manual routing configuration in dynamic.yml for Zitadel
- Configured HTTP/2 Cleartext (h2c) backend for Zitadel service
- Added Zitadel-specific security headers middleware
- Fixed Docker API version compatibility issues

### Secrets Management
- Added Zitadel credentials to test client secrets
- Generated proper 32-character masterkey (Zitadel requirement)
- Created admin password with symbol complexity requirement
- Added zitadel_domain configuration

## Deployment Details

Test environment now accessible at:
- Server: test.vrije.cloud (78.47.191.38)
- Zitadel: https://zitadel.test.vrije.cloud/
- Admin user: admin@test.zitadel.test.vrije.cloud

Successfully tested:
- HTTPS with Let's Encrypt SSL certificate
- Admin login with 2FA setup
- First instance initialization

Fixes #3

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Pieter <pieter@kolabnow.com>
Co-authored-by: Claude <noreply@anthropic.com>
2026-01-05 16:40:37 +01:00
Pieter
0135bd360a Implement OpenTofu infrastructure provisioning (#1)
Completed:
-  Hetzner Cloud provider configuration
-  VPS server provisioning with for_each pattern
-  Cloud firewall rules (SSH, HTTP, HTTPS)
-  SSH key management
-  Outputs for Ansible dynamic inventory
-  Variable structure and documentation
-  Test server successfully provisioned

Deferred:
- DNS configuration (commented out, waiting for domain)

Files added:
- tofu/versions.tf - Provider versions
- tofu/variables.tf - Input variable definitions
- tofu/main.tf - Core infrastructure resources
- tofu/dns.tf - DNS configuration (optional)
- tofu/outputs.tf - Outputs for Ansible integration
- tofu/terraform.tfvars.example - Configuration template
- tofu/README.md - Comprehensive setup guide

Closes #1

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-12-27 13:48:42 +01:00