Es posible que parte de la información de esta página (o toda) no se aplique a Trusted Cloud de S3NS.

Se usó la API de Cloud Translation para traducir esta página.

Configura la autenticación para cargas de trabajo administradas para GKE

En este documento, se explica cómo configurar identidades para cargas de trabajo administradas para Google Kubernetes Engine (GKE) en tus clústeres administrados por flotas de GKE. También se explica cómo implementar una carga de trabajo y verificar su identidad y certificado.

La configuración y el uso de identidades de cargas de trabajo administradas para GKE implican los siguientes pasos:

Configura Certificate Authority Service que te permitan emitir certificados para identidades para cargas de trabajo administradas.
Vincula las CA al grupo de identidades para cargas de trabajo.
Autoriza identidades para cargas de trabajo administradas que te permitan solicitar certificados del grupo de AC.
Implementa cargas de trabajo con identidades para cargas de trabajo administradas.

Grupo de identidades para cargas de trabajo administrado por Google

Cuando agregas tus clústeres a las flotas de GKE, estas crean automáticamente un grupo de identidades de carga de trabajo administrado por Google que sirve como raíz de tu dominio de confianza. El grupo de identidades para cargas de trabajo administrado por Google tiene las siguientes restricciones:

Google administra el grupo por completo, por lo que no puedes crear ningún recurso secundario, como espacios de nombres, identidades o proveedores de identidad.
El grupo solo se puede usar para cargas de trabajo de GKE. No puedes agregar otros tipos de cargas de trabajo, como las VMs de Compute Engine, al grupo.
Todos los clústeres del grupo están sujetos al modelo estándar de igualdad de espacios de nombres de Kubernetes. Esto significa que todos los clústeres del grupo tienen los mismos privilegios. Las cargas de trabajo que se ejecutan en cualquiera de los clústeres del grupo pueden usar cualquier identidad que se encuentre en el grupo.

Configuración de varios proyectos

Trusted Cloud los recursos que usas en este documento, como los clústeres de GKE, la CA raíz y las CA subordinadas, pueden existir en proyectos separados. Cuando hagas referencia a estos recursos, usa la marca --project para especificar el proyecto correcto para cada recurso.

Antes de comenzar

Create or select a Trusted Cloud project.
- Create a Trusted Cloud project:
```
gcloud projects create PROJECT_ID
```
  Replace PROJECT_ID with a name for the Trusted Cloud project you are creating.
- Select the Trusted Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
  Replace PROJECT_ID with your Trusted Cloud project name.

Comprende las identidades para cargas de trabajo administradas.
Asegúrate de tener al menos un clúster de GKE. Asegúrate de que tus clústeres ejecuten la versión 1.33.0-gke.2248000 o posterior.
Agrega tus clústeres a las flotas de GKE. Si tu clúster es de Autopilot, omite --enable-workload-identity. Las flotas crean automáticamente un grupo de identidades para cargas de trabajo administrado por Google que funciona como un dominio de confianza.

Ejecuta el siguiente comando para habilitar las flotas de GKE:
```
gcloud container clusters update CLUSTER_NAME \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-fleet \
    --fleet-project=PROJECT_ID
```
Reemplaza lo siguiente:
- CLUSTER_NAME: Es el nombre del clúster de GKE que deseas registrar en la flota de GKE.
- PROJECT_ID: ID del proyecto host de la flota de GKE
Enable the IAM and Certificate Authority Service APIs:
```
gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com
```
Configura Google Cloud CLI para usar el proyecto de facturación y cuota.
```
gcloud config set billing/quota_project PROJECT_ID
```
Reemplaza PROJECT_ID por el ID del proyecto de flota.

Roles obligatorios

Para obtener los permisos que necesitas para crear identidades para cargas de trabajo administradas y aprovisionar certificados de identidad de cargas de trabajo administrados, pídele a tu administrador que te otorgue los siguientes roles de IAM en el proyecto:

Para crear y configurar identidades para cargas de trabajo administradas, los siguientes roles: Administrador de grupos de identidades para cargas de trabajo de IAM (roles/iam.workloadIdentityPoolAdmin)
Para crear y configurar grupos de AC: Administrador del servicio de AC (roles/privateca.admin)

Para obtener más información sobre cómo otorgar roles, consulta Administra el acceso a proyectos, carpetas y organizaciones.

También puedes obtener los permisos necesarios mediante roles personalizados o cualquier otro rol predefinido.

Configura CA Service para emitir certificados para identidades de cargas de trabajo administradas

Para configurar identidades para cargas de trabajo administradas para GKE, primero debes configurar una entidad certificadora (CA) y una o más CA subordinadas. Esta configuración se conoce como jerarquía de CA.

Puedes usar grupos de CA Service para configurar esta jerarquía. Con esta jerarquía, el grupo de CA subordinada emite los certificados de identidad de carga de trabajo X.509 a tus cargas de trabajo.

Configura tu grupo de AC raíz

Para crear el grupo de AC raíz, haz lo siguiente:

Crea el grupo de AC raíz en el nivel Enterprise con gcloud privateca pools create. Este nivel está destinado a la emisión de certificados de larga duración y bajo volumen.

gcloud privateca pools create ROOT_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=enterprise

Reemplaza lo siguiente:

ROOT_CA_POOL_ID: Es un ID único para el grupo de AC raíz. El ID puede tener hasta 64 caracteres y debe contener solo caracteres alfanuméricos en minúscula y mayúscula, guiones bajos o guiones. El ID del grupo debe ser único dentro de la región.
REGION: Es la región en la que se encuentra el grupo de AC raíz.
CA_PROJECT_ID: Es el ID del proyecto en el que deseas crear la CA raíz.

Para obtener más información sobre los grupos, los niveles y las regiones de la CA, consulta Crea grupos de AC.

Configura tu CA raíz

Crea una CA raíz en el grupo de CA raíz con gcloud privateca roots create. Es posible que se te solicite habilitar la CA raíz si esta es la única en el grupo de CA raíz.

Para crear una CA raíz, ejecuta el siguiente comando:

gcloud privateca roots create ROOT_CA_ID \
    --pool=ROOT_CA_POOL_ID \
    --subject="CN=ROOT_CA_CN, O=ROOT_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --max-chain-length=1 \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --auto-enable

Reemplaza lo siguiente:

ROOT_CA_ID: Es un nombre único para la AC raíz. El nombre de la AC puede tener hasta 64 caracteres y debe contener solo caracteres alfanuméricos en minúscula y mayúscula, guiones bajos o guiones. El nombre de la AC debe ser único dentro de la región.
ROOT_CA_POOL_ID: Es el ID del grupo de AC raíz.
ROOT_CA_CN: Es el nombre de la AC raíz
ROOT_CA_ORGANIZATION: Es la organización de la AC raíz.
KEY_ALGORITHM: El algoritmo de la clave, por ejemplo, ec-p256-sha256
REGION: Es la región en la que se encuentra el grupo de AC raíz.
CA_PROJECT_ID: Es el ID del proyecto en el que creaste la CA raíz.

Para obtener más información sobre los campos subject de la CA, consulta Asunto.

De manera opcional, puedes crear AC raíz adicionales en tu grupo de AC raíz. Esto puede ser útil para la rotación de la CA raíz.

Configura las AC subordinadas

De manera opcional, puedes configurar AC subordinadas. Configurar AC subordinadas puede ayudar con lo siguiente:

Varias situaciones de emisión de certificados: Si tienes varias situaciones de emisión de certificados, puedes crear una CA subordinada para cada situación.
Mejor balanceo de cargas: Agregar varias AC subordinadas en un grupo de AC te ayuda a lograr un mejor balanceo de cargas de solicitudes de certificado.

Para crear un grupo de CA subordinada y una CA subordinada, haz lo siguiente:

Crea el grupo de AC subordinado en el nivel DevOps, que está destinado a la emisión de certificados de corta duración y gran volumen.
```
gcloud privateca pools create SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=devops
```
Reemplaza lo siguiente:
- SUBORDINATE_CA_POOL_ID: Es un ID único para el grupo de AC subordinado. El ID puede tener hasta 64 caracteres y debe contener solo caracteres alfanuméricos en minúscula y mayúscula, guiones bajos o guiones. El ID del grupo debe ser único dentro de la región.
- REGION: Es la región en la que se creará el grupo de AC subordinado.
- CA_PROJECT_ID: Es el ID del proyecto en el que creaste la CA subordinada.
Para obtener más información, consulta Crea grupos de AC.
Crea una CA subordinada en el grupo de AC subordinado. No cambies el modo de emisión basado en la configuración predeterminado.
```
gcloud privateca subordinates create SUBORDINATE_CA_ID \
    --pool=SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --issuer-pool=ROOT_CA_POOL_ID \
    --issuer-location=REGION \
    --subject="CN=SUBORDINATE_CA_CN, O=SUBORDINATE_CA_ORGANIZATION" \
    --key-algorithm="KEY_ALGORITHM" \
    --use-preset-profile=subordinate_mtls_pathlen_0 \
    --project=CA_PROJECT_ID \
    --auto-enable
```
Reemplaza lo siguiente:
- SUBORDINATE_CA_ID: Es un nombre único para la AC subordinada. El nombre puede tener hasta 64 caracteres y debe contener solo caracteres alfanuméricos en minúscula y mayúscula, guiones bajos o guiones. El nombre del grupo debe ser único dentro de la región.
- SUBORDINATE_CA_POOL_ID: Es el nombre del grupo de AC subordinado.
- REGION: Es la región en la que se encuentra el grupo de AC subordinado.
- ROOT_CA_POOL_ID: Es el ID del grupo de AC raíz.
- REGION: Es la región del grupo de AC raíz.
- SUBORDINATE_CA_CN: Es el nombre común de la AC subordinada.
- SUBORDINATE_CA_ORGANIZATION: Es el nombre de la organización emisora de la AC subordinada.
- KEY_ALGORITHM: El algoritmo de la clave, por ejemplo, ec-p256-sha256
- CA_PROJECT_ID: Es el ID del proyecto en el que creaste la CA subordinada.
Para obtener más información sobre los campos subject de la CA, consulta Asunto.

Crea un archivo de configuración de emisión de certificados

Para vincular las AC a los grupos de identidades para cargas de trabajo, deben tener una configuración de emisión de certificados. De manera opcional, si necesitas que tus cargas de trabajo se autentiquen en varios dominios de confianza, también puedes actualizar el grupo con configuraciones de confianza.

Para configurar la configuración de emisión de certificados, debes crear un archivo de configuración de emisión de certificados. El formato del archivo es similar al siguiente:

{
  "inlineCertificateIssuanceConfig": {
      "caPools": {
        "REGION1": "projects/CA_PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1",
        "REGION2": "projects/CA_PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2"
      },
      "lifetime": "DURATION",
      "rotationWindowPercentage": ROTATION_WINDOW_PERCENTAGE,
      "keyAlgorithm": "ALGORITHM"
  }
}

Reemplaza lo siguiente:

REGION: Son las regiones en las que se encuentran las CA.
CA_PROJECT_NUMBER: Es el número del proyecto en el que creaste el grupo de AC subordinado. Para obtener el número de proyecto del proyecto CA_PROJECT_ID, ejecuta el siguiente comando:
```
gcloud projects describe CA_PROJECT_ID --format="value(projectNumber)"
```
SUBORDINATE_CA_POOL_ID: Es el nombre del grupo de AC subordinado.
ALGORITHM: Opcional Es el algoritmo de encriptación que se usó para generar la clave privada. Los valores válidos son ECDSA_P256 (predeterminado), ECDSA_P384, RSA_2048, RSA_3072 y RSA_4096.
DURATION: Opcional Es la duración de validez del certificado de hoja, en segundos. El valor debe estar entre 86,400 (1 día) y 2,592,000 (30 días). Si no se especifica, se usa el valor predeterminado de 86,400 (1 día). La validez real del certificado emitido también depende de la AC que lo emite, ya que puede restringir su vida útil.
ROTATION_WINDOW_PERCENTAGE: Es el porcentaje de vida útil del certificado en el que se activa una renovación (opcional). El valor debe estar entre 50 y 80. El valor predeterminado es 50.

Crea el archivo de configuración de confianza

De forma predeterminada, tus cargas de trabajo dentro del mismo dominio de confianza pueden autenticarse mutuamente con identidades para cargas de trabajo administradas. Si quieres que las cargas de trabajo que se encuentran en dominios de confianza diferentes se autentiquen mutuamente, debes declarar explícitamente la relación de confianza en el grupo de identidades para cargas de trabajo. Para ello, crea un archivo de configuración de confianza que contenga un inlineTrustConfig que proporcione certificados para cada dominio.

El archivo de configuración de confianza contiene un conjunto de anclajes de confianza que la identidad administrada de la carga de trabajo usa para validar los certificados de intercambio de tráfico. El archivo de configuración de confianza asigna el dominio de confianza de SPIFFE a los certificados de CA.

Para crear el archivo de configuración de confianza, haz lo siguiente:

Descarga los certificados.
```
gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \
    --output-file=CERTIFICATE_PATH \
    --location=REGION
```
Reemplaza lo siguiente:
- ROOT_CA_POOL_ID: ID del grupo de AC raíz
- CERTIFICATE_PATH: Es la ruta de acceso en la que se generará el certificado codificado en PEM.
- REGION: la región del grupo de AC raíz

Crea un archivo que contenga tu configuración de confianza intercalada, con certificados en formato PEM. El archivo es similar al siguiente:

{
  "inlineTrustConfig": {
    "additionalTrustBundles": {
      "TRUST_DOMAIN_NAME1": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL1\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL2\n-----END CERTIFICATE-----"
          }
        ]
      },
      "TRUSTED_DOMAIN_NAME2": {
        "trustAnchors": [
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL3\n-----END CERTIFICATE-----"
          },
          {
              "pemCertificate": "-----BEGIN CERTIFICATE-----\nCERTIFICATE_MATERIAL4\n-----END CERTIFICATE-----"
          }
        ]
      }
    }
  }
}

Reemplaza lo siguiente:

TRUST_DOMAIN_NAME: Es el nombre del dominio de confianza, con el siguiente formato:
```
PROJECT_ID.svc.id.goog
```
CERTIFICATE_MATERIAL: Es un conjunto de certificados de AC con formato PEM que se confía para emitir certificados en el dominio de confianza.

Vincula las CA al grupo de identidades para cargas de trabajo

Después de crear tu jerarquía de CA y las configuraciones de emisión de certificados para cada CA, vincula las CA al grupo de identidades para cargas de trabajo. Para vincular una CA al grupo de identidades para cargas de trabajo, actualiza el grupo de identidades para cargas de trabajo con la configuración de emisión de certificados de la CA. Luego, puedes verificar que el grupo se haya actualizado.

Actualiza el grupo de identidades para cargas de trabajo

Para actualizar el grupo, ejecuta el siguiente comando:

gcloud iam workload-identity-pools update TRUST_DOMAIN_NAME \
    --location="global" \
    --inline-certificate-issuance-config-file=CIC_JSON_FILE_PATH \
    --inline-trust-config-file=TC_JSON_FILE_PATH \
    --project=PROJECT_ID

Reemplaza lo siguiente:

TRUST_DOMAIN_NAME: Es el nombre del dominio de confianza, con el siguiente formato:
```
PROJECT_ID.svc.id.goog
```
CIC_JSON_FILE_PATH: Es la ruta de acceso al archivo de configuración de emisión de certificados con formato JSON (cic.json) que creaste anteriormente.
TC_JSON_FILE_PATH: Opcional Ruta de acceso al archivo de configuración de confianza con formato JSON (tc.json) que creaste anteriormente. Si tus cargas de trabajo se autentican en diferentes dominios de confianza, debes especificar este archivo. De lo contrario, puedes omitir --inline-trust-config.

Verifica que se haya actualizado el grupo de identidades para cargas de trabajo

Para verificar que tu grupo de identidades para cargas de trabajo se haya actualizado junto con la configuración de emisión de certificados y la configuración de confianza, ejecuta el siguiente comando:

gcloud iam workload-identity-pools describe TRUST_DOMAIN_NAME \
    --location="global" \
    --project=PROJECT_ID

Reemplaza TRUST_DOMAIN_NAME por el nombre del dominio de confianza que usaste para actualizar el grupo de identidades para cargas de trabajo anteriormente en este documento.

El resultado del comando es similar al siguiente:

inlineCertificateIssuanceConfig:
    caPools:
      REGION1: projects/PROJECT_NUMBER1/locations/REGION1/caPools/SUBORDINATE_CA_POOL_ID1,
      REGION2: projects/PROJECT_NUMBER2/locations/REGION2/caPools/SUBORDINATE_CA_POOL_ID2
    keyAlgorithm: ALGORITHM
    lifetime: DURATION
    rotationWindowPercentage: ROTATION_WINDOW_PERCENTAGE
inlineTrustConfig:
    additionalTrustBundles:
      example.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL1
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL2
            -----END CERTIFICATE-----
      myorg.com:
          trustAnchors:
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL3
            -----END CERTIFICATE-----
          - pemCertificate: |-
            -----BEGIN CERTIFICATE-----
            CERTIFICATE_MATERIAL4
            -----END CERTIFICATE-----
name: PROJECT_ID.svc.id.goog
state: ACTIVE

Si inlineCertificateIssuanceConfig o inlineTrustConfig no están presentes en el resultado del comando, verifica que hayas configurado correctamente tu gcloud CLI para usar el proyecto correcto para la facturación y la cuota. Es posible que debas actualizar a una versión más reciente de gcloud CLI.

Autoriza identidades para cargas de trabajo administradas que permitan solicitar certificados del grupo de AC

Después de vincular las AC al grupo de identidades para cargas de trabajo, debes autorizar a las identidades para cargas de trabajo administradas a solicitar certificados del grupo de AC. Para autorizar estas identidades, haz lo siguiente:

Otorga el rol de IAM Solicitante de certificados de cargas de trabajo del servicio de AC (roles/privateca.workloadCertificateRequester) en cada grupo de AC subordinado al dominio de confianza. El siguiente comando gcloud privateca pools add-iam-policy-binding autoriza al dominio de confianza para solicitar certificados de las cadenas de certificados del servicio de CA.
```
gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.workloadCertificateRequester \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \
    --project=CA_PROJECT_ID
```
Reemplaza lo siguiente:
- SUBORDINATE_CA_POOL_ID: Es el ID del grupo de AC subordinado.
- REGION: Es la región del grupo de AC subordinado.
- PROJECT_NUMBER: Es el número del proyecto que contiene el grupo de identidades para cargas de trabajo de GKE.
  
  Para obtener PROJECT_NUMBER de PROJECT_ID, ejecuta el siguiente comando:
```
gcloud projects describe PROJECT_ID --format="value(projectNumber)"
```
- PROJECT_ID: Es el ID del proyecto host de la flota de GKE.
- CA_PROJECT_ID: Es el ID del proyecto en el que creaste la CA subordinada.
Otorga el rol de Lector de grupos de servicios de CA (roles/privateca.poolReader) en los grupos de AC subordinados a la identidad de carga de trabajo administrada. De esta manera, se autoriza a la identidad para cargas de trabajo administrada a obtener los certificados X.509 firmados de las cadenas de certificados de la CA.
```
gcloud privateca pools add-iam-policy-binding SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --role=roles/privateca.poolReader \
    --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/name/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog" \
    --project=CA_PROJECT_ID
```
Reemplaza lo siguiente:
- SUBORDINATE_CA_POOL_ID: Es el ID del grupo de AC subordinado.
- REGION: Es la región del grupo de AC subordinado.
- PROJECT_NUMBER: Es el número del proyecto que contiene el grupo de identidades para cargas de trabajo de GKE.
- PROJECT_ID: Es el ID del proyecto host de la flota de GKE.
- CA_PROJECT_ID: Es el ID del proyecto en el que creaste la CA subordinada.

Implementa cargas de trabajo con identidades para cargas de trabajo administradas

Después de configurar tus grupos de AC para que emitan certificados para identidades para cargas de trabajo administradas, puedes implementar cargas de trabajo que tengan identidades para cargas de trabajo administradas.

En esta sección, se muestra cómo implementar una carga de trabajo de prueba que tiene una identidad para cargas de trabajo administrada. Para ello, implementarás un Pod, verificarás que se hayan generado las credenciales y verás el certificado y el ID de SPIFFE.

Implementa un Pod

Para implementar un Pod de prueba en tu clúster, haz lo siguiente:

Obtén las credenciales del clúster.

gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_ZONE \
    --project=CLUSTER_PROJECT_ID

Crea el espacio de nombres de Kubernetes.

kubectl create namespace KUBERNETES_NAMESPACE

Implementa un PodSpec de prueba.

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  namespace: KUBERNETES_NAMESPACE
  name: example-pod
spec:
  containers:
  - name: main
    image: debian
    command: ['sleep', 'infinity']
    volumeMounts:
    - name: fleet-spiffe-credentials
      mountPath: /var/run/secrets/workload-spiffe-credentials
      readOnly: true
  nodeSelector:
    iam.gke.io/gke-metadata-server-enabled: "true"
  volumes:
  - name: fleet-spiffe-credentials
    csi:
      driver: podcertificate.gke.io
      volumeAttributes:
        signerName: spiffe.gke.io/fleet-svid
        trustDomain: fleet-project/svc.id.goog
EOF

Enumera las credenciales de la carga de trabajo

Para enumerar las credenciales de la carga de trabajo, ejecuta el siguiente comando. La creación de las credenciales puede tardar unos minutos.

kubectl exec -it example-pod -n KUBERNETES_NAMESPACE -- ls  /var/run/secrets/workload-spiffe-credentials

Deberías ver el siguiente resultado:

ca_certificates.pem
certificates.pem
private_key.pem
trust_bundles.json

Cómo ver el certificado

Para ver el certificado, haz lo siguiente:

Exporta el certificado a un archivo de certificado.

kubectl exec -it example-pod --namespace=KUBERNETES_NAMESPACE -- cat /var/run/secrets/workload-spiffe-credentials/certificates.pem | openssl x509 -noout -text > certfile

Consulta el archivo del certificado.
```
cat certfile
```
En el certificado, en el atributo X509v3 Subject Alternative Name, verás el ID de SPIFFE, con el siguiente formato: spiffe://PROJECT_ID.svc.id.goog/ns/KUBERNETES_NAMESPACE/sa/default

default hace referencia a la ServiceAccount predeterminada de Kubernetes.

Prueba la autenticación de carga de trabajo a carga de trabajo

Para probar la autenticación de carga de trabajo a carga de trabajo, consulta Prueba la autenticación de mTLS con Go.

El código de muestra del repositorio crea cargas de trabajo de cliente y servidor. Puedes probar la autenticación mutua entre las cargas de trabajo con los certificados que generaste antes en este documento.

¿Qué sigue?

Soluciona problemas de la identidad para cargas de trabajo administrada para GKE.
Más información para crear grupos de AC.