Epic: Migrate create-config target from mc-bootstrap to mcli

[anvddriesch]

Epic: Replace mc-bootstrap scripts with integrated mcli commands

Overview

Currently, management cluster configuration is handled by mc-bootstrap's create-config target, which orchestrates ~18 different scripts. This epic aims to replace this complex scripting with integrated mcli commands that provide a cleaner, more maintainable interface for configuration management.

Repository Architecture

Per-Customer Repositories (created from templates)

1. Customer Config Repository (CCR): giantswarm/{customer}-configs

   • Template: giantswarm/template-configs
   • Contains: Customer-specific configurations, installation secrets (SOPS-encrypted)
   • Secrets: SSH deploy keys, SOPS age keys, installation-specific secrets

2. Customer Management Cluster Repository (CMC): giantswarm/{customer}-management-clusters

   • Template: giantswarm/template-customer-mc
   • Contains: Management cluster manifests, cluster secrets (SOPS-encrypted)
   • Secrets: SSH deploy keys (3 types), SOPS age keys, Kubernetes secrets

Shared Repositories (one for all customers)

• giantswarm/shared-configs: Shared configuration templates
• giantswarm/installations: Installation metadata and cluster definitions

Current mc-bootstrap Analysis

The create-config target currently orchestrates:

• 9 secret generation scripts (~812 lines total)
• Repository management scripts (CCR creation, CMC setup, config branching)
• Provider-specific setup (CAPA, CAPZ, CAPV, CAPVCD)
• Integration scripts (Sentry, monitoring, alerting)

Key complexity:

• setup-config-branch.sh (707 lines)
• setup-cmc-branch.sh (879 lines estimated)
• Multiple provider-specific conditional flows

Implementation Phases

Phase 1: Repository Management Commands 🏗️

Goal: Implement repository-centric commands with integrated secret management

1.1: Customer Config Repository (CCR) Management

• mcli create config --customer {customer} - Create giantswarm/{customer}-configs from template
• mcli push config --installation {installation} - Push to existing CCR (replace setup-config-branch.sh)
• mcli pull config --installation {installation} - Pull from existing CCR
• Integrated secrets: SSH deploy keys, SOPS age keys, installation secrets
• Replaces: create-customer-config-repository.sh, setup-config-branch.sh (707 lines)

1.2: Customer Management Cluster Repository (CMC) Management

• mcli create cmc --customer {customer} - ✅ Already exists
• mcli push cmc --installation {installation} - Push to existing CMC (enhance setup-cmc-branch.sh)
• mcli pull cmc --installation {installation} - Pull from existing CMC
• Integrated secrets: SSH deploy keys (CMC, CCR, shared-configs), SOPS age keys, K8s secrets
• Replaces: Enhanced setup-cmc-branch.sh (879 lines)

1.3: Shared Repository Management

• mcli push installations - ✅ Already exists
• mcli push shared --type {configs|installations} - Push to shared repositories
• mcli pull shared --type {configs|installations} - Pull from shared repositories

Phase 2: Modular Secret Management 🔐

Goal: Standalone secret commands (also used internally by repository commands)

2.1: Secret Generation

mcli secrets generate --type {type} --installation {installation}

Types: teleport, dex, age, ssh-deploy, azurecr, slack, grafana, event-exporter, opsgenie

• Replaces: 9 generate-* scripts (~812 lines)
• Storage: GitHub (SOPS-encrypted) + 1Password for age keys

2.2: Secret Retrieval

mcli secrets pull --installation {installation} --from {github|1password}

• Replaces: op-pull-secrets.sh (291 lines)
• New approach: GitHub-centric with 1Password only for age keys

Phase 3: Provider Setup Commands 🌐

Goal: Standalone provider setup (also used internally by repository commands)

3.1: Provider Infrastructure Setup

mcli provider setup --provider {capa|capz|capv|capvcd} --installation {installation}

• CAPA: create-capa-controller-user.sh
• CAPZ: verify-static-sp-credentials.sh, setup-mc-identities-with-az.sh
• CAPV/CAPVCD: Provider-specific setup scripts

3.2: Provider Validation

mcli provider validate --provider {provider}

• Pre-flight validation before configuration
• Credential and prerequisite checking

Phase 4: Integration Commands 🔌

Goal: Handle external service integrations

4.1: Service Integrations

mcli integrations setup --type {sentry} --installation {installation}

• Replaces: sentry-add-configs.sh (29 lines)
• Extensible: For future monitoring, logging, security integrations

Phase 5: High-Level Orchestration 🎯

Goal: Single command replacement for create-config

5.1: Unified Configuration Command

mcli config create --installation {installation} --provider {provider} --customer {customer}

• Replaces: Entire create-config target
• Orchestrates: All repository, secret, provider, and integration commands
• Maintains: Environment variable compatibility

5.2: mc-bootstrap Integration

# Updated Makefile.custom.mk
create-config: check-envs env install-tools
	mcli config create --installation $(INSTALLATION) --provider $(PROVIDER) --customer $(CUSTOMER)

5.3: Migration Documentation

• Command mapping guide (old scripts → new mcli commands)
• Environment variable compatibility matrix
• Troubleshooting guide for edge cases

Success Criteria

Technical

• All 18 mc-bootstrap scripts replaced with mcli commands
• SOPS encryption/decryption maintained
• Provider-specific logic preserved
• 1Password integration retained for age keys
• GitHub-centric secret storage implemented

Operational

• Backward compatibility maintained via updated Makefile
• Reduced complexity: ~2000 lines of bash → structured Go commands
• Improved error handling and validation
• Better secret management with GitHub storage

User Experience

• Intuitive repository-centric command structure
• Modular commands for specific operations
• Clear migration path from existing workflows

Implementation Strategy

1. Start with Phase 1.1 (CCR management) - most isolated
2. Enhance existing Phase 1.2 (CMC management) - builds on current mcli create cmc
3. Parallel development of Phases 2-3 (secrets and providers)
4. Integration Phase 4-5 (orchestration and migration)
5. Comprehensive testing with existing installations

Technical Dependencies

• SOPS integration for encryption/decryption
• GitHub API access for repository management
• 1Password CLI for age key management
• Provider CLIs (aws, az, etc.) for infrastructure setup
• Age encryption for secret management

Risk Mitigation

• Gradual migration: Keep existing scripts until replacement is validated
• Feature parity: Ensure all current functionality is preserved
• Extensive testing: Validate with multiple provider/customer combinations
• Rollback capability: Maintain ability to revert to mc-bootstrap if needed