Post-X-Society/Post-Tyranny-Tech-Infrastructure
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
48 commits 3 branches 3 tags 498 KiB
Commit graph

4 commits

Author SHA1 Message Date
Pieter
ac4187d041 feat: Automate SSH key and secrets generation in deployment scripts 
Simplify client deployment workflow by automating SSH key generation and
secrets file creation. No more manual preparation steps!

## Changes

### Deploy Script Automation
**`scripts/deploy-client.sh`**:
- Auto-generates SSH key pair if missing (calls generate-client-keys.sh)
- Auto-creates secrets file from template if missing
- Opens SOPS editor for user to customize secrets
- Continues with deployment after setup complete

### Rebuild Script Automation
**`scripts/rebuild-client.sh`**:
- Same automation as deploy script
- Ensures SSH key and secrets exist before rebuild

### Documentation Updates
- **`README.md`** - Updated quick start workflow
- **`scripts/README.md`** - Updated script descriptions and examples

## Workflow: Before vs After

### Before (Manual)
```bash
# 1. Generate SSH key
./scripts/generate-client-keys.sh newclient

# 2. Create secrets file
cp secrets/clients/template.sops.yaml secrets/clients/newclient.sops.yaml
sops secrets/clients/newclient.sops.yaml

# 3. Add to terraform.tfvars
vim tofu/terraform.tfvars

# 4. Deploy
./scripts/deploy-client.sh newclient
```

### After (Automated)
```bash
# 1. Add to terraform.tfvars
vim tofu/terraform.tfvars

# 2. Deploy (everything else is automatic!)
./scripts/deploy-client.sh newclient
# Script automatically:
# - Generates SSH key if missing
# - Creates secrets file from template if missing
# - Opens editor for you to customize
# - Continues with deployment
```

## Benefits

✅ **Fewer manual steps**: 4 steps → 2 steps
✅ **Less error-prone**: Can't forget to generate SSH key
✅ **Better UX**: Script guides you through setup
✅ **Still flexible**: Can pre-create SSH key/secrets if desired
✅ **Idempotent**: Won't regenerate if already exists

## Backward Compatible

Existing workflows still work:
- If SSH key already exists, script uses it
- If secrets file already exists, script uses it
- Can still use generate-client-keys.sh manually if preferred

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

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-01-17 20:04:29 +01:00
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
9571782382 fix: Restore Mailgun SMTP and Nextcloud OIDC integration 
Fixes three critical regressions from previous deployment:

1. **Mailgun SMTP Credentials**
   - Added mailgun_api_key to secrets/shared.sops.yaml
   - Updated deploy.yml to load and merge shared secrets
   - Mailgun credentials now created automatically per client

2. **Nextcloud OIDC Integration**
   - OIDC provider creation now works (was timing issue)
   - "Login with Authentik" button restored on Nextcloud login

3. **Infrastructure Deployment**
   - Fixed deploy-client.sh to create full infrastructure (DNS + server)
   - Removed -target flag that caused incomplete deployments

Changes:
- ansible/playbooks/deploy.yml: Load shared secrets and merge into client_secrets
- secrets/shared.sops.yaml: Add Mailgun API key for all clients
- secrets/clients/dev.sops.yaml: Add dev client configuration
- scripts/deploy-client.sh: Apply full infrastructure without -target flag

All services now functional:
✅ Traefik reverse proxy with auto SSL
✅ Authentik SSO with email configuration
✅ Nextcloud with OIDC login and email
✅ Mailgun SMTP credentials (dev@mg.vrije.cloud)

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

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-01-14 16:04:00 +01:00
Pieter
a5fe631717 feat: Complete Authentik SSO integration with automated OIDC setup 
## Changes

### Identity Provider (Authentik)
- ✅ Deployed Authentik 2025.10.3 as identity provider
- ✅ Configured automatic bootstrap with admin account (akadmin)
- ✅ Fixed OIDC provider creation with correct redirect_uris format
- ✅ Added automated OAuth2/OIDC provider configuration for Nextcloud
- ✅ API-driven provider setup eliminates manual configuration

### Nextcloud Configuration
- ✅ Fixed reverse proxy header configuration (trusted_proxies)
- ✅ Added missing database indices (fs_storage_path_prefix)
- ✅ Ran mimetype migrations for proper file type handling
- ✅ Verified PHP upload limits (16GB upload_max_filesize)
- ✅ Configured OIDC integration with Authentik
- ✅ "Login with Authentik" button auto-configured

### Automation Scripts
- ✅ Added deploy-client.sh for automated client deployment
- ✅ Added rebuild-client.sh for infrastructure rebuild
- ✅ Added destroy-client.sh for cleanup
- ✅ Full deployment now takes ~10-15 minutes end-to-end

### Documentation
- ✅ Updated README with automated deployment instructions
- ✅ Added SSO automation workflow documentation
- ✅ Added automation status tracking
- ✅ Updated project reference with Authentik details

### Technical Fixes
- Fixed Authentik API redirect_uris format (requires list of dicts with matching_mode)
- Fixed Nextcloud OIDC command (user_oidc:provider not user_oidc:provider:add)
- Fixed file lookup in Ansible (changed to slurp for remote files)
- Updated Traefik to v3.6 for Docker API 1.44 compatibility
- Improved error handling in app installation tasks

## Security
- All credentials stored in SOPS-encrypted secrets
- Trusted proxy configuration prevents IP spoofing
- Bootstrap tokens auto-generated and secured

## Result
Fully automated SSO deployment - no manual configuration required!

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

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-01-08 16:56:19 +01:00