Accede a los Secrets almacenados fuera de los clústeres de GKE mediante bibliotecas cliente

Autopilot estándar

En este instructivo, se muestra cómo almacenar los datos sensibles que usan tus clústeres de Google Kubernetes Engine (GKE) en Secret Manager. Aprenderás a acceder a los datos desde tus Pods de forma más segura con la federación de identidades para cargas de trabajo para GKE y lasGoogle Cloud bibliotecas cliente.

Almacenar los datos sensibles fuera del almacenamiento de tu clúster reduce el riesgo de acceso no autorizado a los datos si se produce un ataque. Usar la federación de identidades para cargas de trabajo para GKE para acceder a los datos te permite evitar los riesgos asociados con la administración de claves de cuentas de servicio de larga duración y te permite controlar el acceso a tus Secrets mediante Identity and Access Management (IAM) en lugar de reglas de RBAC en el clúster. Puedes usar cualquier proveedor de almacén de Secrets externo, como Secret Manager o HashiCorp Vault.

Esta página está dirigida a los especialistas en seguridad que desean mover datos sensibles fuera del almacenamiento dentro del clúster. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes del usuario de GKE.

En este instructivo, se usa un clúster de GKE Autopilot. Para realizar los pasos con GKE Standard, debes habilitar la federación de identidades para cargas de trabajo para GKE de forma manual.

Puedes usar la federación de identidades para cargas de trabajo para GKE para acceder a cualquier Google Cloud API desde cargas de trabajo de GKE sin tener que usar enfoques menos seguros, como los archivos de claves de cuentas de servicio estáticos. En este instructivo, se usa Secret Manager como ejemplo, pero puedes seguir los mismos pasos para acceder a otras APIs de Google Cloud. Si deseas obtener más información, consulta Federación de identidades para cargas de trabajo para GKE.

Objetivos

• Crea un secreto en Google Cloud Secret Manager.
• Crear un clúster de Autopilot de GKE, espacios de nombres de Kubernetes y cuentas de servicio de Kubernetes.
• Crea políticas de permisos de IAM para otorgar acceso a tus cuentas de servicio de Kubernetes en el secreto.
• Usar aplicaciones de prueba para verificar el acceso de la cuenta de servicio.
• Ejecutar una app de muestra que acceda al Secret con la API de Secret Manager.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

• GKE Autopilot
• Secret Manager

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios.

Es posible que los usuarios de Google Cloud nuevos cumplan con los requisitos para acceder a una prueba gratuita.

Cuando completes las tareas que se describen en este documento, podrás borrar los recursos que creaste para evitar que se te siga facturando. Para obtener más información, consulta Realiza una limpieza.

Antes de comenzar

Accede a tu cuenta de Google Cloud . Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Instala Google Cloud CLI.

Si usas un proveedor de identidad externo (IdP), primero debes acceder a la gcloud CLI con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente comando:

gcloud init

Crea o selecciona un Google Cloud proyecto.

Roles necesarios para seleccionar o crear un proyecto

• Selecciona un proyecto: Para seleccionar un proyecto, no se requiere un rol de IAM específico. Puedes seleccionar cualquier proyecto en el que se te haya otorgado un rol.
• Crear un proyecto: Para crear un proyecto, necesitas el rol de Creador de proyectos (roles/resourcemanager.projectCreator), que contiene el permiso resourcemanager.projects.create. Obtén más información para otorgar roles.

Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

• Crea un proyecto de Google Cloud :

  gcloud projects create PROJECT_ID

  Reemplaza PROJECT_ID por un nombre para el proyecto Google Cloud que estás creando.

• Selecciona el proyecto Google Cloud que creaste:

  gcloud config set project PROJECT_ID

  Reemplaza PROJECT_ID por el nombre de tu Google Cloud proyecto.

Verifica que la facturación esté habilitada para tu proyecto de Google Cloud .

Habilita las APIs de Kubernetes Engine y Secret Manager:

Roles necesarios para habilitar las APIs

Para habilitar las APIs, necesitas el rol de IAM de administrador de Service Usage (roles/serviceusage.serviceUsageAdmin), que contiene el permiso serviceusage.services.enable. Obtén más información para otorgar roles.

gcloud services enable container.googleapis.com secretmanager.googleapis.com

Instala Google Cloud CLI.

Si usas un proveedor de identidad externo (IdP), primero debes acceder a la gcloud CLI con tu identidad federada.

Para inicializar gcloud CLI, ejecuta el siguiente comando:

gcloud init

Crea o selecciona un Google Cloud proyecto.

Roles necesarios para seleccionar o crear un proyecto

• Selecciona un proyecto: Para seleccionar un proyecto, no se requiere un rol de IAM específico. Puedes seleccionar cualquier proyecto en el que se te haya otorgado un rol.
• Crear un proyecto: Para crear un proyecto, necesitas el rol de Creador de proyectos (roles/resourcemanager.projectCreator), que contiene el permiso resourcemanager.projects.create. Obtén más información para otorgar roles.

Nota: Si no planeas conservar los recursos que creaste durante este procedimiento, crea un proyecto en lugar de seleccionar uno existente. Cuando termines, puedes borrar el proyecto y quitar todos los recursos asociados con él.

• Crea un proyecto de Google Cloud :

  gcloud projects create PROJECT_ID

  Reemplaza PROJECT_ID por un nombre para el proyecto Google Cloud que estás creando.

• Selecciona el proyecto Google Cloud que creaste:

  gcloud config set project PROJECT_ID

  Reemplaza PROJECT_ID por el nombre de tu Google Cloud proyecto.

Verifica que la facturación esté habilitada para tu proyecto de Google Cloud .

Habilita las APIs de Kubernetes Engine y Secret Manager:

Roles necesarios para habilitar las APIs

Para habilitar las APIs, necesitas el rol de IAM de administrador de Service Usage (roles/serviceusage.serviceUsageAdmin), que contiene el permiso serviceusage.services.enable. Obtén más información para otorgar roles.

gcloud services enable container.googleapis.com secretmanager.googleapis.com

1. Otorga roles a tu cuenta de usuario. Ejecuta el siguiente comando una vez para cada uno de los siguientes roles de IAM: roles/secretmanager.admin, roles/container.clusterAdmin

   gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE

   Reemplaza lo siguiente:

   • PROJECT_ID: ID del proyecto
   • USER_IDENTIFIER: Es el identificador de tu cuenta de usuario de . Por ejemplo, [e-mail].
   • ROLE: Es el rol de IAM que otorgas a tu cuenta de usuario.

Prepare el entorno

Clona el repositorio de GitHub que contiene los archivos de muestra para este instructivo:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd ~/kubernetes-engine-samples/security/wi-secrets

Crea un Secret en Secret Manager

1. En el siguiente ejemplo, se muestran los datos que usarás para crear un Secret:

   key=my-api-key

2. Crea un Secret para almacenar los datos de muestra:

   gcloud secrets create bq-readonly-key \
       --data-file=manifests/bq-readonly-key \
       --ttl=3600s
   

   Este comando realiza las siguientes acciones:

   • Crea un nuevo Secret de Secret Manager con la clave de muestra en la región us-central1 Google Cloud .
   • Configura el Secret para que venza una hora después de ejecutar el comando.

Crea el clúster y los recursos de Kubernetes

Crea un clúster de GKE, espacios de nombres de Kubernetes y cuentas de servicio de Kubernetes. Deberás crear dos espacios de nombres, uno para el acceso de solo lectura y otro para el acceso de lectura y escritura al Secret. También deberás crear una cuenta de servicio de Kubernetes en cada espacio de nombres a fin de usarla con la federación de identidades para cargas de trabajo para GKE.

1. Crea un clúster de GKE Autopilot:

   gcloud container clusters create-auto secret-cluster \
       --location=us-central1
   

   La implementación del clúster puede tomar unos cinco minutos. Los clústeres de Autopilot siempre tienen habilitada la federación de identidades para cargas de trabajo para GKE. Si, en cambio, deseas usar un clúster de GKE Standard, debes habilitar de forma manual la federación de identidades para cargas de trabajo para GKE antes de continuar.

2. Crea un espacio de nombres readonly-ns y un espacio de nombres admin-ns:

   kubectl create namespace readonly-ns
   kubectl create namespace admin-ns
   

3. Crea una cuenta de servicio de Kubernetes readonly-sa y una cuenta de servicio de Kubernetes admin-sa:

   kubectl create serviceaccount readonly-sa --namespace=readonly-ns
   kubectl create serviceaccount admin-sa --namespace=admin-ns
   

Crea políticas de permisos de IAM

1. Otorga a la cuenta de servicio readonly-sa acceso de solo lectura al Secret:

   gcloud secrets add-iam-policy-binding bq-readonly-key \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/readonly-ns/sa/readonly-sa \
       --role='roles/secretmanager.secretAccessor' \
       --condition=None
   

   Reemplaza lo siguiente:

   • PROJECT_NUMBER: Es el número de proyecto numérico de Google Cloud.
   • PROJECT_ID: Es el ID del proyecto de Google Cloud .

2. Otorga a la cuenta de servicio admin-sa acceso de lectura y escritura al Secret:

   gcloud secrets add-iam-policy-binding bq-readonly-key \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/admin-ns/sa/admin-sa \
       --role='roles/secretmanager.secretAccessor' \
       --condition=None
   gcloud secrets add-iam-policy-binding bq-readonly-key \
       --member=principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/admin-ns/sa/admin-sa \
       --role='roles/secretmanager.secretVersionAdder' \
       --condition=None
   

Verifica el acceso al Secret

Implementa Pods de prueba en cada espacio de nombres para verificar el acceso de solo lectura y el de lectura y escritura.

1. Revisa el manifiesto del Pod de solo lectura:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Pod
   metadata:
     name: readonly-test
     namespace: readonly-ns
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
       resources:
         requests:
           cpu: "150m"
           memory: "150Mi"
     serviceAccountName: readonly-sa

   Este pod usa la cuenta de servicio readonly-sa en el espacio de nombres readonly-ns.

2. Revisa el manifiesto del Pod de lectura y escritura:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Pod
   metadata:
     name: admin-test
     namespace: admin-ns
   spec:
     containers:
     - image: google/cloud-sdk:slim
       name: workload-identity-test
       command: ["sleep","infinity"]
       resources:
         requests:
           cpu: "150m"
           memory: "150Mi"
     serviceAccountName: admin-sa

   Este pod usa la cuenta de servicio admin-sa en el espacio de nombres admin-ns.

3. Implementa los Pods de prueba:

   kubectl apply -f manifests/admin-pod.yaml
   kubectl apply -f manifests/readonly-pod.yaml
   

   Los Pods pueden tardar unos minutos en comenzar a ejecutarse. Para supervisar el progreso, ejecuta el siguiente comando:

   watch kubectl get pods -n readonly-ns
   

   Cuando el estado del Pod cambie a RUNNING, presiona Ctrl+C para volver a la línea de comandos.

Prueba el acceso de solo lectura

1. Abre una shell en el Pod readonly-test:

   kubectl exec -it readonly-test --namespace=readonly-ns -- /bin/bash
   

2. Intenta leer el Secret:

   gcloud secrets versions access 1 --secret=bq-readonly-key
   

   El resultado es key=my-api-key.

3. Intenta escribir datos nuevos en el Secret:

   printf "my-second-api-key" | gcloud secrets versions add bq-readonly-key --data-file=-
   

   El resultado es similar a este:

   ERROR: (gcloud.secrets.versions.add) PERMISSION_DENIED: Permission 'secretmanager.versions.add' denied for resource 'projects/PROJECT_ID/secrets/bq-readonly-key' (or it may not exist).
   

   El pod que usa la cuenta de servicio de solo lectura solo puede leer el Secret y no puede escribir datos nuevos.

4. Sal del pod:

   exit
   

Prueba el acceso de lectura y escritura

1. Abre una shell en el Pod admin-test:

   kubectl exec -it admin-test --namespace=admin-ns -- /bin/bash
   

2. Intenta leer el Secret:

   gcloud secrets versions access 1 --secret=bq-readonly-key
   

   El resultado es key=my-api-key.

3. Intenta escribir datos nuevos en el Secret:

   printf "my-second-api-key" | gcloud secrets versions add bq-readonly-key --data-file=-
   

   El resultado es similar a este:

   Created version [2] of the secret [bq-readonly-key].
   

4. Lee la versión nueva del Secret:

   gcloud secrets versions access 2 --secret=bq-readonly-key
   

   El resultado es my-second-api-key.

5. Sal del pod:

   exit
   

Los pods solo obtienen el nivel de acceso que otorgaste a la cuenta de servicio de Kubernetes que se usó en el manifiesto del pod. Cualquier pod que use la cuenta de Kubernetes admin-sa en el espacio de nombres admin-ns puede escribir versiones nuevas del Secret, pero cualquier pod en el espacio de nombres readonly-ns que use la cuenta de servicio de Kubernetes readonly-sa solo puede leer el Secret.

Accede a los Secrets desde tu código

En esta sección, harás lo siguiente:

1. Implementa una aplicación de muestra que lea tu Secret en Secret Manager mediante bibliotecas cliente.

2. Verifica que la aplicación pueda acceder a tu Secret.

Debes acceder a los Secrets de Secret Manager desde el código de tu aplicación siempre que sea posible mediante la API de Secret Manager.

1. Revisa el código fuente de la aplicación de muestra:

   // Copyright 2022 Google LLC
   //
   // Licensed under the Apache License, Version 2.0 (the "License");
   // you may not use this file except in compliance with the License.
   // You may obtain a copy of the License at
   //
   //     http://www.apache.org/licenses/LICENSE-2.0
   //
   // Unless required by applicable law or agreed to in writing, software
   // distributed under the License is distributed on an "AS IS" BASIS,
   // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   // See the License for the specific language governing permissions and
   // limitations under the License.
   
   package main
   
   import (
   	"context"
   	"fmt"
   	"log"
   	"os"
   
   	secretmanager "cloud.google.com/go/secretmanager/apiv1"
   	secretmanagerpb "google.golang.org/genproto/googleapis/cloud/secretmanager/v1"
   )
   
   func main() {
   
           // Get environment variables from Pod spec.
           projectID := os.Getenv("PROJECT_ID")
           secretId := os.Getenv("SECRET_ID")
           secretVersion := os.Getenv("SECRET_VERSION")
   
           // Create the Secret Manager client.
           ctx := context.Background()
           client, err := secretmanager.NewClient(ctx)
           if err != nil {
                   log.Fatalf("failed to setup client: %v", err)
           }
           defer client.Close()
   
           // Create the request to access the secret.
           accessSecretReq := &secretmanagerpb.AccessSecretVersionRequest{
                   Name: fmt.Sprintf("projects/%s/secrets/%s/versions/%s", projectID, secretId, secretVersion),
           }
   
           secret, err := client.AccessSecretVersion(ctx, accessSecretReq)
           if err != nil {
                   log.Fatalf("failed to access secret: %v", err)
           }
   
           // Print the secret payload.
           //
           // WARNING: Do not print the secret in a production environment - this
           // snippet is showing how to access the secret material.
           log.Printf("Welcome to the key store, here's your key:\nKey: %s", secret.Payload.Data)
   }
   

   Esta aplicación llama a la API de Secret Manager para intentar leer el Secret.

2. Revisa el manifiesto del Pod de la aplicación de muestra:

   # Copyright 2022 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: v1
   kind: Pod
   metadata:
     name: readonly-secret-test
     namespace: readonly-ns
   spec:
     containers:
     - image: us-docker.pkg.dev/google-samples/containers/gke/wi-secret-store:latest
       name: secret-app
       env:
         - name: PROJECT_ID
           value: "YOUR_PROJECT_ID"
         - name: SECRET_ID
           value: "bq-readonly-key"
         - name: SECRET_VERSION
           value: "latest"
       resources:
         requests:
           cpu: "125m"
           memory: "64Mi"
     serviceAccountName: readonly-sa

   Este manifiesto hace lo siguiente:

   • Crea un Pod en el espacio de nombres readonly-ns que usa la cuenta de servicio readonly-sa.
   • Extrae una aplicación de muestra de un registro de imágenes de Google. Esta aplicación llama a la API de Secret Manager con lasGoogle Cloud bibliotecas cliente. Puedes ver el código de la aplicación en /main.go en el repositorio.
   • Configura las variables de entorno para que use la aplicación de muestra.

3. Reemplaza las variables de entorno en la aplicación de muestra:

   sed -i "s/YOUR_PROJECT_ID/PROJECT_ID/g" "manifests/secret-app.yaml"
   

4. Implementa la app de muestra:

   kubectl apply -f manifests/secret-app.yaml
   

   Es posible que el Pod tarde unos minutos en comenzar a trabajar. Si el Pod necesita un nodo nuevo en tu clúster, es posible que notes eventos de tipo CrashLoopBackOff mientras a través de GKE se proporciona el nodo. Las fallas se detienen cuando el nodo aprovisiona correctamente.

5. Verifica el acceso al Secret:

   kubectl logs readonly-secret-test -n readonly-ns
   

   El resultado es my-second-api-key. Si el resultado está en blanco, es posible que el Pod aún no se esté ejecutando. Espere unos minutos y vuelva a intentarlo.

Enfoques alternativos

Si necesitas activar tus datos sensibles en tus Pods, usa el complemento de Secret Manager para GKE. Este complemento implementa y administra el proveedor de Google Cloud Secret Manager para el controlador de CSI de Kubernetes Secret Store en tus clústeres de GKE. Para obtener instrucciones, consulta Usa el complemento de Secret Manager con GKE.

Proporcionar Secrets como volúmenes activados tiene los siguientes riesgos:

1. Los volúmenes activados son susceptibles a los ataques de recorrido del directorio.
2. Las variables de entorno pueden verse comprometidas debido a configuraciones incorrectas, como cuando se abre un extremo de depuración.

Siempre que sea posible, te recomendamos que accedas a los Secrets de manera programática a través de la API de Secret Manager. Para obtener instrucciones, usa la aplicación de muestra de este instructivo o consulta Bibliotecas cliente de Secret Manager.

Realiza una limpieza

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra los recursos individuales

1. Borra el clúster:

   gcloud container clusters delete secret-cluster \
       --location=us-central1
   

2. Opcional: borra el Secret en Secret Manager.

   gcloud secrets delete bq-readonly-key
   

   Si no realizas este paso, el Secret vencerá automáticamente porque configuraste la marca --ttl durante su creación.

Borra el proyecto

Precaución: Borrar un proyecto tiene las siguientes consecuencias:

• Se borra todo su contenido. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
• Se pierden los IDs personalizados de los proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID personalizado del proyecto que desees utilizar en el futuro. Para conservar las URLs que usan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto, en lugar de todo el proyecto.

Si planeas explorar varios instructivos, arquitecturas o guías de inicio rápido, reutilizar proyectos puede ser útil para no exceder los límites de cuota de los proyectos.

Borra un Google Cloud proyecto:

gcloud projects delete PROJECT_ID

¿Qué sigue?

• Obtén información para autenticarte en las Google Cloud APIs desde cargas de trabajo de GKE.
• Obtén más información para encriptar Secrets en la capa de la aplicación.
• Obtén más información sobre la federación de identidades para cargas de trabajo para GKE.
• Obtén más información para instalar kubectl y configurar el acceso al clúster.
• Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.