Gestión de Secretos Multi-Cloud para PYMEs con External Secrets Operator

Por /

Gestión de Secretos Multi-Cloud para PYMEs con External Secrets Operator

Asegura y simplifica los secretos en múltiples entornos cloud. Implementa External Secrets Operator en Kubernetes para una integración fluida con los almacenes de claves cloud.

Para las Pequeñas y Medianas Empresas (PYMEs) que operan en un entorno multi-cloud o híbrido, gestionar datos sensibles como claves API, credenciales de bases de datos y certificados puede convertirse rápidamente en un importante dolor de cabeza operativo y de seguridad. Almacenar secretos directamente en los manifiestos de Kubernetes es un importante antipatrón, y sincronizarlos manualmente entre múltiples clústeres y almacenes de proveedores cloud es propenso a errores y consume mucho tiempo. Aquí es donde el External Secrets Operator (ESO) de Kubernetes se convierte en una herramienta invaluable, permitiendo una integración perfecta con sistemas externos de gestión de secretos como AWS Secrets Manager, Azure Key Vault o Google Secret Manager.

This article will guide you through the process of implementing External Secrets Operator in your Kubernetes clusters to establish a robust, automated, and secure multi-cloud secrets management solution. This approach builds upon best practices for securing credentials without enterprise tools, adapting them for a dynamic multi-cloud landscape.

El Desafío de la Gestión de Secretos Multi-Cloud

A medida que crecen las PYMEs, también lo hace la complejidad de su infraestructura. Ejecutar aplicaciones en AWS, Azure y Google Cloud, o incluso en on-premise, significa lidiar con soluciones de gestión de secretos dispares. Cada proveedor cloud ofrece su propio almacén robusto (ej. AWS Secrets Manager, Azure Key Vault, GCP Secret Manager), pero conectar estos a tus cargas de trabajo de Kubernetes de forma segura y eficiente a través de diferentes entornos presenta varios obstáculos:

  • Sincronización Manual: Copying secrets from cloud vaults into Kubernetes Secret objects is a manual process, prone to errors, and creates a security risk by duplicating sensitive data.
  • Falta de Centralización: Sin un enfoque unificado, los equipos pueden crear secretos en diferentes almacenes, lo que genera inconsistencias y dificultades en la auditoría.
  • Complejidad de Rotación: La rotación manual de secretos es tediosa y a menudo se descuidada, aumentando la superficie de ataque.
  • Carga de Cumplimiento: Garantizar que los secretos se gestionen de acuerdo con los estándares de cumplimiento (ej., SOC 2, HIPAA) se vuelve mucho más difícil sin automatización.

While topics like “securing builds with SBOMs and image signing” address supply chain security, secrets management is a foundational layer often overlooked.

Presentando External Secrets Operator (ESO)

External Secrets Operator is a Kubernetes operator that integrates external secret management systems into Kubernetes. It acts as a bridge, allowing you to define ExternalSecret objects in Kubernetes which reference secrets stored in external vaults. ESO then fetches these secrets and automatically creates or updates native Kubernetes Secret objects with the retrieved data.

Beneficios Clave de ESO:

  • Integración Perfecta: Se conecta directamente a varios gestores de secretos de proveedores cloud (AWS, Azure, GCP), HashiCorp Vault y más.
  • Sincronización Automatizada: Sincroniza automáticamente los secretos de almacenes externos a Kubernetes, eliminando la intervención manual.
  • Seguridad Mejorada: Secrets never reside permanently in your Git repository and are only materialized as native Kubernetes Secret objects within the cluster when needed.
  • Soporte de Rotación: When secrets are rotated in the external vault, ESO automatically fetches the updated values and refreshes the corresponding Kubernetes Secret.
  • Agnóstico de Multi-Cloud: Proporciona una forma consistente de gestionar secretos independientemente del proveedor cloud subyacente.

Desplegando External Secrets Operator en tu Clúster

Para empezar, necesitarás un clúster de Kubernetes y Helm instalado. Desplegaremos ESO usando Helm.

Instalación con Helm

Agrega el repositorio de Helm de External Secrets:

helm repo add external-secrets https://charts.external-secrets.io
helm repo update

Instala el External Secrets Operator:

kubectl create namespace external-secrets
helm install external-secrets external-secrets/external-secrets \
    -n external-secrets \
    --set installCRDs=true

The --set installCRDs=true flag ensures that the Custom Resource Definitions (CRDs) for ExternalSecret, SecretStore, and ClusterSecretStore are installed.

Configurando un SecretStore para AWS Secrets Manager

Once ESO is running, you need to tell it where to find your external secrets. This is done using a SecretStore or ClusterSecretStore resource. A SecretStore is namespaced, while a ClusterSecretStore is cluster-scoped and can be used by ExternalSecret objects in any namespace.

Para AWS Secrets Manager, necesitarás un rol IAM con permisos para acceder a tus secretos. Este rol debe ser asumido por la cuenta de servicio de Kubernetes que ejecuta ESO (o un pod de aplicación específico si configuras Workload Identity).

Ejemplo de Política IAM (para AWS Secrets Manager)

Crea una política IAM como esta:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret"
            ],
            "Resource": [
                "arn:aws:secretsmanager:REGION:ACCOUNT_ID:secret:your-secret-name-*"
            ]
        }
    ]
}

Adjunta esta política a un rol IAM que tu cuenta de servicio de Kubernetes pueda asumir (ej., vía IRSA en EKS o mecanismos similares en otras nubes). Para simplificar, supongamos que el propio controlador ESO tiene los permisos necesarios. En un escenario de producción, utiliza roles IAM detallados para cada aplicación.

Definición de SecretStore

Create a SecretStore to connect to AWS Secrets Manager. Save this as aws-secretstore.yaml:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: aws-secret-store
  namespace: my-app-namespace
spec:
  provider:
    aws:
      service: SecretsManager
      region: us-east-1
      auth:
        jwt:
          serviceAccountRef:
            name: external-secrets-controller
            namespace: external-secrets

Aplícalo:

kubectl apply -f aws-secretstore.yaml

This SecretStore tells ESO how to authenticate with AWS Secrets Manager.

Creando un ExternalSecret y Sincronizándolo con Kubernetes

Now, let us define an ExternalSecret that references a secret in AWS Secrets Manager and instructs ESO to create a native Kubernetes Secret from it.

Ejemplo de Secreto en AWS Secrets Manager

Imagine you have a secret in AWS Secrets Manager named my-database-credentials with a JSON value like:

{
    "username": "dbuser",
    "password": "***"
}

Definición de ExternalSecret

Create my-external-secret.yaml in the my-app-namespace:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: my-app-db-secret
  namespace: my-app-namespace
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: aws-secret-store
    kind: SecretStore
  target:
    name: my-app-db-credentials
    creationPolicy: Owner
  data:
    - secretKey: db_username
      remoteRef:
        key: my-database-credentials
        property: username
    - secretKey: db_password
      remoteRef:
        key: my-database-credentials
        property: password

Apply this ExternalSecret:

kubectl apply -f my-external-secret.yaml

ESO will now fetch the values from my-database-credentials in AWS Secrets Manager, extract username y password, and create a Kubernetes Secret named my-app-db-credentials in my-app-namespace. You can verify this:

kubectl get secret my-app-db-credentials -n my-app-namespace -o yaml

Conclusión

External Secrets Operator proporciona una solución robusta y elegante para la gestión de secretos multi-cloud en Kubernetes. Al desacoplar los secretos de tus manifiestos de aplicación y delegar su ciclo de vida a almacenes externos especializados, las PYMEs pueden mejorar significativamente su postura de seguridad, simplificar las operaciones y garantizar el cumplimiento. Esta automatización reduce el riesgo de error humano y permite que tus equipos de DevOps se centren en aportar valor, en lugar de gestionar manualmente credenciales sensibles en entornos dispares. Adoptar herramientas como ESO es un paso fundamental hacia una estrategia nativa de la nube más madura y segura.

Struggling with secrets management or multi-cloud complexity? Book a free 30-minute consultation with our DevOps experts to streamline your operations.

es_ESEspañol
en_GBEnglish es_ESEspañol
Scroll al inicio