[RFE] GKE - Alternatives to service Account JSON Key

[palexus]

Is your feature request related to a problem? Please describe.

Currently, Rancher's GKE cluster provisioning only supports Service Account JSON keys for authentication with Google Cloud Platform. This creates significant security and compliance challenges:

Security Risks:

• JSON service account keys are long-lived credentials that never expire automatically
• Keys must be stored and transmitted as plaintext files, increasing exposure risk
• No built-in key rotation mechanisms, requiring manual intervention
• Keys provide broad, persistent access that violates the principle of least privilege
• Compromised keys can be used indefinitely until manually revoked

Compliance Issues:

• ISO 27001 non-compliance: The standard requires strong access controls and credential management practices. Long-lived service account keys violate several controls:
  • A.9.2.1 (User registration and de-registration)
  • A.9.2.3 (Management of privileged access rights)
  • A.9.4.3 (Password management system)
• Fails security audit requirements for credential lifecycle management
• Does not meet enterprise security policies requiring short-lived, rotatable credentials

Operational Challenges:

• Manual key rotation processes are error-prone and often neglected
• Difficulty in tracking and auditing key usage across environments
• Increased attack surface due to persistent credential storage

Describe the solution you'd like

Implement Workload Identity Federation as the primary authentication method for GKE cluster provisioning, with the following capabilities:

Primary Solution: Workload Identity Federation

• Support for federated identity providers (GitHub Actions, GitLab CI, Azure AD, etc.)
• Short-lived, automatically rotating access tokens
• Attribute-based access control without persistent secrets
• Integration with existing CI/CD pipelines and infrastructure-as-code workflows

Enhanced Authentication Options:

1. Application Default Credentials (ADC) support for environments where Rancher runs on GCP
2. OAuth 2.0 device flow for interactive authentication scenarios
3. Workload Identity for GKE-hosted Rancher instances
4. Service Account impersonation with time-limited tokens

Implementation Requirements:

• Backward compatibility with existing JSON key configurations
• Clear migration path from JSON keys to federated identity
• Comprehensive documentation and examples
• Support for multiple authentication methods per cluster configuration

Describe alternatives you've considered

1. External Secret Management Integration

• Integrate with HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault
• Automatic key rotation through external systems
• Limitation: Still relies on long-lived keys, just with better storage

2. Service Account Key Auto-Rotation

• Implement automatic key generation and rotation within Rancher
• Limitation: Doesn't eliminate the fundamental security risks of long-lived keys

3. Proxy Authentication Service

• Create an intermediate authentication service that handles GCP credentials
• Limitation: Adds complexity and potential single point of failure

4. Manual Documentation Improvements

• Provide better guidance on key rotation and security practices
• Limitation: Doesn't address the underlying architectural security flaws

Why These Alternatives Are Insufficient:
None of these alternatives eliminate the core security vulnerability of long-lived credentials. Only Workload Identity Federation provides the zero-trust, keyless authentication model required for modern enterprise security standards.

Additional context

Industry Standards and Best Practices:

• Google Cloud officially recommends Workload Identity Federation over service account keys
• Major cloud providers (AWS, Azure) have moved away from long-lived credentials
• NIST Cybersecurity Framework emphasizes identity and access management controls
• Zero Trust Architecture principles require eliminating long-lived secrets

Business Impact:

• Compliance Requirements: Many enterprises cannot adopt Rancher for GKE due to security policy violations
• Audit Failures: Current implementation fails security audits and penetration tests
• Risk Management: Insurance and compliance costs increase due to credential-based attack vectors
• Competitive Disadvantage: Other Kubernetes management platforms already support modern authentication methods

Technical Precedents:

• Terraform GCP provider supports Workload Identity Federation
• kubectl and gcloud CLI tools support federated authentication
• Google Cloud Build, Cloud Run, and other GCP services use Workload Identity by default

Proposed Implementation Timeline:

1. Phase 1: Add Workload Identity Federation support alongside existing JSON keys
2. Phase 2: Implement migration tools and documentation
3. Phase 3: Deprecate JSON key authentication with clear sunset timeline
4. Phase 4: Remove JSON key support in favor of secure authentication methods

Related Security Standards:

• ISO 27001:2013 - Information Security Management Systems
• SOC 2 Type II - Security and Availability Trust Services
• NIST Cybersecurity Framework - Identity and Access Management
• CIS Kubernetes Benchmark - Authentication and Authorization controls

This feature request is critical for enabling enterprise adoption of Rancher in security-conscious organizations and maintaining compliance with international security standards.