Configurar la autenticación de Workload Identity gestionado para GKE

En este documento se explica cómo configurar identidades de carga de trabajo gestionadas para Google Kubernetes Engine (GKE) en los clústeres gestionados por flotas de GKE. También se explica cómo desplegar una carga de trabajo y verificar su identidad y su certificado.

Para configurar y usar identidades de carga de trabajo gestionadas en GKE, debes seguir estos pasos:

  1. Configura el Servicio de Autoridades de Certificación para que emita certificados para identidades de cargas de trabajo gestionadas.

  2. Vincula las CAs al grupo de identidades de carga de trabajo.

  3. Autoriza a las identidades de carga de trabajo gestionadas para que soliciten certificados del grupo de ACs.

  4. Despliega cargas de trabajo con identidades de carga de trabajo gestionadas.

Grupo de identidades de carga de trabajo gestionado por Google

Cuando añades tus clústeres a flotas de GKE, las flotas crean automáticamente un grupo de identidades de carga de trabajo gestionado por Google que actúa como raíz de tu dominio de confianza. El grupo de identidades de carga de trabajo gestionado por Google tiene las siguientes restricciones:

  • Google gestiona el grupo por completo, por lo que no puedes crear ningún subrecurso, como espacios de nombres, identidades o proveedores de identidades.

  • El pool solo se puede usar para cargas de trabajo de GKE. No puedes añadir otros tipos de cargas de trabajo, como máquinas virtuales 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 pool tienen los mismos privilegios. Las cargas de trabajo que se ejecutan en cualquiera de los clústeres del grupo pueden usar cualquier identidad que esté en el grupo.

Configuración multiproyecto

LosTrusted Cloud recursos que utilices en este documento, como los clústeres de GKE, la AC raíz y las ACs subordinadas, pueden estar en proyectos independientes. Cuando haga referencia a estos recursos, utilice la marca --project para especificar el proyecto correcto de cada recurso.

Antes de empezar

  1. 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.

  2. Familiarízate con las identidades de cargas de trabajo gestionadas.

  3. 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 una posterior.

  4. Añade tus clústeres a flotas de GKE. Si tu clúster es de Autopilot, omite --enable-workload-identity. Fleets crea automáticamente un grupo de identidades de carga de trabajo gestionado por Google que actúa como dominio de confianza.

    Habilita las flotas de GKE ejecutando el siguiente comando:

    gcloud container clusters update CLUSTER_NAME \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --enable-fleet \
    --fleet-project=PROJECT_ID

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre del clúster de GKE que quieres registrar en la flota de GKE
    • PROJECT_ID: el ID del proyecto host de la flota de GKE

  5. Enable the IAM and Certificate Authority Service APIs: 

    gcloud services enable cloudresourcemanager.googleapis.com iam.googleapis.com privateca.googleapis.com

  6. Configura la CLI de Google Cloud para que use el proyecto de facturación y cuota.

    gcloud config set billing/quota_project PROJECT_ID

    Sustituye PROJECT_ID por el ID del proyecto de la flota.

Roles obligatorios

Para obtener los permisos que necesitas para crear identidades de carga de trabajo gestionadas y aprovisionar certificados de identidad de carga de trabajo gestionados, pide a tu administrador que te conceda los siguientes roles de gestión de identidades y accesos en el proyecto:

Para obtener más información sobre cómo conceder roles, consulta el artículo Gestionar el acceso a proyectos, carpetas y organizaciones.

También puedes conseguir los permisos necesarios a través de roles personalizados u otros roles predefinidos.

Configurar el servicio de AC para emitir certificados de identidades de cargas de trabajo gestionadas

Para configurar identidades de carga de trabajo gestionadas en GKE, primero debes configurar una autoridad de certificación (CA) y una o varias CAs subordinadas. Esta configuración se conoce como jerarquía de CAs.

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

Configurar el grupo de autoridades de certificación raíz

Para crear el grupo de AC raíz, siga estos pasos:

Crea el grupo de AC raíz en el nivel Enterprise con gcloud privateca pools create. Este nivel está pensado para 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

Haz los cambios siguientes:

  • ROOT_CA_POOL_ID: ID único del grupo de ACs raíz. El ID puede tener hasta 64 caracteres y solo puede contener caracteres alfanuméricos en mayúsculas y minúsculas, guiones bajos o guiones. El ID del grupo debe ser único en la región.

  • REGION: la región en la que se encuentra el grupo de autoridades de certificación raíz.

  • CA_PROJECT_ID: el ID del proyecto en el que quieres crear la CA raíz.

Para obtener más información sobre los grupos, los niveles y las regiones de las AC, consulta Crear grupos de autoridades de certificación.

Configurar la CA raíz

Crea una AC raíz en el grupo de ACs raíz con gcloud privateca roots create. Es posible que se te pida que habilite la CA raíz si es la única CA del 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

Haz los cambios siguientes:

  • ROOT_CA_ID: nombre único de la CA raíz. El nombre de la autoridad de certificación puede tener hasta 64 caracteres y solo puede contener caracteres alfanuméricos en minúsculas y mayúsculas, guiones bajos o guiones. El nombre de la CA debe ser único en la región.
  • ROOT_CA_POOL_ID: el ID del grupo de autoridades de certificación raíz.
  • ROOT_CA_CN: nombre común de la CA raíz.
  • ROOT_CA_ORGANIZATION: la organización de la autoridad de certificación raíz.
  • KEY_ALGORITHM: el algoritmo de la clave (por ejemplo, ec-p256-sha256).
  • REGION: la región en la que se encuentra el grupo de autoridades de certificación raíz.
  • CA_PROJECT_ID: el ID del proyecto en el que has creado la CA raíz.

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

También puedes crear ACs raíz adicionales en tu grupo de ACs raíz. Esto puede ser útil para la rotación de la CA raíz.

Configurar ACs subordinadas

También puedes configurar CAs subordinadas. Configurar CAs subordinadas puede ayudarte con lo siguiente:

  • Varios casos de emisión de certificados: si tienes varios casos de emisión de certificados, puedes crear una AC subordinada para cada uno de ellos.

  • Mejor balanceo de carga: si añades varias ACs subordinadas a un grupo de ACs, podrás conseguir un mejor balanceo de carga de las solicitudes de certificados.

Para crear un grupo de autoridades de certificación subordinada y una autoridad de certificación subordinada, sigue estos pasos:

  1. Crea el grupo de AC subordinada en el nivel DevOps, que está diseñado para emitir un gran volumen de certificados de corta duración.

    gcloud privateca pools create SUBORDINATE_CA_POOL_ID \
    --location=REGION \
    --project=CA_PROJECT_ID \
    --tier=devops

    Haz los cambios siguientes:

    • SUBORDINATE_CA_POOL_ID: ID único del grupo de CAs secundarias. El ID puede tener hasta 64 caracteres y solo puede contener caracteres alfanuméricos en minúscula y mayúscula, guiones bajos o guiones. El ID del grupo debe ser único en la región.
    • REGION: la región en la que se creará el pool de ACs subordinadas.
    • CA_PROJECT_ID: el ID del proyecto en el que has creado la AC subordinada.

    Para obtener más información, consulta Crear grupos de CAs.

  2. Crea una AC subordinada en el grupo de ACs subordinadas. 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

    Haz los cambios siguientes:

    • SUBORDINATE_CA_ID: nombre único de la CA subordinada. El nombre puede tener hasta 64 caracteres y solo puede incluir caracteres alfanuméricos en minúsculas y mayúsculas, guiones bajos o guiones. El nombre del grupo debe ser único en la región.
    • SUBORDINATE_CA_POOL_ID: el nombre del grupo de AC subordinada.
    • REGION: la región en la que se encuentra el grupo de AC subordinado.
    • ROOT_CA_POOL_ID: el ID del grupo de autoridades de certificación raíz.
    • REGION: la región del grupo de autoridades de certificación raíz.
    • SUBORDINATE_CA_CN: nombre común de la AC subordinada.
    • SUBORDINATE_CA_ORGANIZATION: 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: el ID del proyecto en el que has creado la AC subordinada.

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

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

Para vincular autoridades de certificación a grupos de identidades de carga de trabajo, deben tener una configuración de emisión de certificados. 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"
  }
}

Haz los cambios siguientes:

  • REGION: las regiones en las que se encuentran las autoridades de certificación.

  • CA_PROJECT_NUMBER: número del proyecto en el que has creado el grupo de autoridades de certificación subordinadas. 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: nombre del grupo de ACs subordinadas.

  • ALGORITHM: opcional. El algoritmo de cifrado usado para generar la clave privada. Los valores válidos son ECDSA_P256 (predeterminado), ECDSA_P384, RSA_2048, RSA_3072 y RSA_4096.

  • DURATION: opcional. Duración de la validez del certificado de hoja, en segundos. El valor debe estar comprendido entre 86.400 (1 día) y 2.592.000 (30 días). Si no se especifica, se usa el valor predeterminado 86400 (1 día). La validez real del certificado emitido también depende de la AC emisora, ya que puede restringir la duración del certificado emitido.

  • ROTATION_WINDOW_PERCENTAGE: Opcional: porcentaje del tiempo de validez del certificado en el que se activa una renovación. El valor debe estar comprendido entre 50 y 80. El valor predeterminado es 50.

Crear el archivo de configuración de confianza

De forma predeterminada, tus cargas de trabajo del mismo dominio de confianza pueden autenticarse mutuamente mediante identidades de carga de trabajo gestionadas. Si quieres que las cargas de trabajo que se encuentran en diferentes dominios de confianza se autentiquen mutuamente, debes declarar explícitamente la relación de confianza en el grupo de identidades de carga 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 anclas de confianza que la identidad de carga de trabajo gestionada usa para validar los certificados de los pares. 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:

  1. Descarga los certificados. 

    gcloud privateca pools get-ca-certs ROOT_CA_POOL_ID \
    --output-file=CERTIFICATE_PATH \
    --location=REGION

    Haz los cambios siguientes:

    • ROOT_CA_POOL_ID: el ID del grupo de autoridades de certificación raíz
    • CERTIFICATE_PATH: la ruta en la que se generará el certificado codificado en PEM.
    • REGION: la región del grupo de autoridades de certificación raíz

  2. Crea un archivo llamado que contenga tu configuración de confianza insertada con certificados en formato PEM. El archivo tendrá un aspecto 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-----"
          }
        ]
      }
    }
  }
}

    Haz los cambios siguientes:

    • TRUST_DOMAIN_NAME: nombre del dominio de confianza con el siguiente formato: 
      PROJECT_ID.svc.id.goog
    • CERTIFICATE_MATERIAL: conjunto de certificados de AC en formato PEM de confianza para emitir certificados en el dominio de confianza.

Vincular las CAs al grupo de identidades de carga de trabajo

Después de crear la jerarquía de AC y las configuraciones de emisión de certificados de cada AC, vincula las AC al grupo de identidades de carga de trabajo. Para vincular una CA al grupo de identidades de carga de trabajo, actualiza el grupo de identidades de carga de trabajo con la configuración de emisión de certificados de la CA. A continuación, puedes verificar que el grupo se ha actualizado.

Actualizar el grupo de identidades de carga 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

Haz los cambios siguientes:

  • TRUST_DOMAIN_NAME: nombre del dominio de confianza, con el siguiente formato:

    PROJECT_ID.svc.id.goog

  • CIC_JSON_FILE_PATH: la ruta al archivo de configuración de emisión de certificados en formato JSON (cic.json) que has creado anteriormente.

  • TC_JSON_FILE_PATH: opcional. Ruta al archivo de configuración de confianza con formato JSON (tc.json) que has creado 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.

Verificar que se ha actualizado el grupo de identidades de carga de trabajo

Para verificar que tu grupo de identidades de carga de trabajo se ha 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

Sustituye TRUST_DOMAIN_NAME por el nombre del dominio de confianza que has usado para actualizar el grupo de identidades de carga de trabajo anteriormente en este documento.

La salida del comando es similar a la 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 aparecen en el resultado del comando, comprueba que has configurado correctamente la CLI de gcloud para que use el proyecto adecuado para la facturación y la cuota. Es posible que tengas que actualizar a una versión más reciente de la CLI de gcloud.

Autorizar identidades de carga de trabajo gestionadas para solicitar certificados del grupo de ACs

Después de vincular las CAs al grupo de identidades de carga de trabajo, debes autorizar a las identidades de carga de trabajo gestionadas para que soliciten certificados al grupo de CAs. Para autorizar estas identidades, sigue estos pasos:

  1. Asigna el rol de gestión de identidades y accesos Solicitante del certificado de carga de trabajo del Servicio de Autoridades de Certificación (roles/privateca.workloadCertificateRequester) al dominio de confianza en cada grupo de AC subordinada. El siguiente gcloud privateca pools add-iam-policy-binding comando autoriza al dominio de confianza a solicitar certificados de las cadenas de certificados del Servicio de Autoridades de Certificación.

    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

    Haz los cambios siguientes:

    • SUBORDINATE_CA_POOL_ID: ID del grupo de ACs subordinadas.
    • REGION: la región del grupo de ACs subordinadas.

    • PROJECT_NUMBER: el número de proyecto del proyecto que contiene el grupo de identidades de carga 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: ID del proyecto host de la flota de GKE.

    • CA_PROJECT_ID: el ID del proyecto en el que has creado la AC subordinada.

  2. Asigna el rol Lector del grupo de autoridades de certificación (roles/privateca.poolReader) a los grupos de autoridades de certificación subordinadas a la identidad de carga de trabajo gestionada. De esta forma, se autoriza a la identidad de carga de trabajo gestionada para 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

    Haz los cambios siguientes:

    • SUBORDINATE_CA_POOL_ID: el ID del grupo de autoridades de certificación subordinado.
    • REGION: la región del grupo de ACs subordinadas.
    • PROJECT_NUMBER: el número del proyecto que contiene el grupo de identidades de carga de trabajo de GKE.
    • PROJECT_ID: ID del proyecto host de la flota de GKE.
    • CA_PROJECT_ID: el ID del proyecto en el que has creado la AC subordinada.

Desplegar cargas de trabajo con identidades de carga de trabajo gestionadas

Una vez que hayas configurado tus grupos de ACs para que emitan certificados para identidades de carga de trabajo gestionadas, podrás desplegar cargas de trabajo que tengan identidades de carga de trabajo gestionadas.

En esta sección se muestra cómo desplegar una carga de trabajo de prueba que tenga una identidad de carga de trabajo gestionada. Para ello, despliega un pod, comprueba que se han generado las credenciales y consulta el certificado y el ID de SPIFFE.

Desplegar un pod

Para desplegar un pod de prueba en tu clúster, haz lo siguiente:

  1. Obtén las credenciales del clúster.

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

  2. Crea el espacio de nombres de Kubernetes.

    kubectl create namespace KUBERNETES_NAMESPACE

  3. Despliega 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

Mostrar las credenciales de carga de trabajo

Para enumerar las credenciales de 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 este resultado:

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

Ver el certificado

Para ver el certificado, haz lo siguiente:

  1. 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

  2. Consulta el archivo de 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 cuenta de servicio de Kubernetes predeterminada.

Probar 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 Probar la autenticación mTLS con Go.

El código de ejemplo 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 has generado anteriormente en este documento.

Siguientes pasos