Autorisation des pods d'accéder à des ressources non OCI à l'aide du repérage OpenID Connect (OIDC)

Découvrez comment utiliser le repérage OpenID Connect (OIDC) pour authentifier les pods d'application exécutés sur les clusters que vous créez avec Container Engine for Kubernetes (OKE), afin que les pods puissent appeler des API de service sur des fournisseurs cloud externes.

Vous pouvez souhaiter que les pods d'application s'exécutent sur un cluster Kubernetes que vous avez créé avec Kubernetes Engine afin de communiquer avec les API de service cloud hébergées sur des fournisseurs cloud externes (tels que GCP, AWS et Azure). Pour garantir la sécurité des ressources hébergées par un fournisseur cloud externe, l'application exécutée sur le cluster doit authentifier et gérer l'identité. Toutefois, la gestion directe des informations d'identification peut être un processus fastidieux pour les applications, et la rotation des clés est un processus manuel avec une surcharge considérable.

OpenID Connect (OIDC) est une norme du secteur pour rendre ces intégrations plus simples. OpenID Connect est une couche d'identité basée sur OAuth 2.0. OpenID Connect prend en charge un protocole de découverte (souvent appelé "découverte OIDC") qui utilise un document de configuration de fournisseur OpenID (appelé "document de découverte") pour authentifier les applications.

Kubernetes Engine prend en charge le repérage OIDC, ce qui vous permet de créer des applications qui interagissent avec d'autres services cloud sans avoir à coder en dur ni à faire pivoter manuellement les clés d'authentification d'API. Vous pouvez éventuellement activer le repérage OIDC lorsque vous créez ou mettez à jour un cluster amélioré à l'aide de Kubernetes Engine.

En général, lorsque vous activez le repérage OIDC pour un cluster, le jeton de compte de service de l'application est authentifié et (s'il est valide) échangé contre un jeton d'accès. Le jeton d'accès est ensuite utilisé pour authentifier l'application auprès de l'API sur le fournisseur cloud externe.

Pour plus d'informations, reportez-vous à Découverte de l'émetteur de compte de service dans la documentation Kubernetes.

Repérage OIDC plus en détail

Kubernetes attribue un compte de service à chaque pod d'application exécuté sur un cluster et crée un jeton de compte de service pour chaque compte de service. Kubernetes gère le cycle de vie des jetons de compte de service. Le jeton de compte de service est un jeton de support que l'application attache aux demandes d'API. Il est structuré en tant que jeton Web JSON (JWT).

Lorsque vous activez le repérage OIDC pour un cluster, Kubernetes Engine affiche un émetteur OIDC et ajoute l'URL de l'émetteur OIDC au jeton de compte de service en tant que valeur de la demande iss.

L'emplacement d'un document de repérage OIDC est relatif à l'URL de l'émetteur OIDC. Il s'agit d'une adresse connue accessible au public et non authentifiée. Le document de repérage OIDC inclut l'emplacement non authentifié et accessible au public d'un ensemble de clés Web JSON (JWKS) contenant les clés publiques permettant de vérifier le jeton de compte de service. Le fournisseur d'identités du fournisseur cloud externe utilise le document de repérage OIDC pour localiser le JWKS et le JWKS pour vérifier le jeton de compte de service.

Pour plus de sécurité, l'API de service cloud appelée par un pod d'application peut nécessiter la présence d'une audience particulière dans le jeton de compte de service créé par Kubernetes. Si l'API de service cloud requiert une audience particulière, vous pouvez indiquer cette audience en définissant la propriété audience d'un volume projeté dans le manifeste de pod. L'audience que vous indiquez est incluse en tant que valeur de la réclamation aud dans le jeton de compte de service, et peut ensuite être vérifiée par le fournisseur cloud externe. Vous pouvez également spécifier une période de validité pour le jeton de compte de service en définissant la valeur de la propriété expirationSeconds du volume projeté dans le manifeste de pod. Pour plus d'informations, reportez-vous à la projection de volume de jeton ServiceAccount dans la documentation Kubernetes.

Si le fournisseur d'identités du fournisseur cloud externe vérifie le jeton de compte de service à l'aide de JWKS, le fournisseur d'identités échange le jeton de compte de service contre un jeton d'accès. Le jeton d'accès est ensuite utilisé pour authentifier l'application et l'autoriser à utiliser l'API sur le fournisseur cloud externe.

Processus d'échange de jetons de repérage OIDC

Lorsque vous activez le repérage OIDC pour un cluster afin qu'un pod d'application puisse envoyer une demande à une API externe, Kubernetes Engine affiche :

Un émetteur OIDC. L'émetteur OIDC est exposé via HTTPS avec un certificat TLS/SSL public.
Ensemble de clés Web JSON (JWKS), contenant les clés publiques utilisées pour vérifier le jeton de compte de service. Le JWKS est stocké dans un bucket non authentifié et accessible publiquement dans le service Object Storage. Reportez-vous à Exemple JWKS.
Document de repérage OIDC (au format JSON) qui inclut l'emplacement du JWKS. Le document de repérage est stocké dans un bucket non authentifié et accessible publiquement dans le service Object Storage. Reportez-vous à la section Discovery Document Example.

Lors de la définition d'un pod d'application qui envoie des demandes à une API externe, si le fournisseur d'identités du fournisseur de cloud externe attend une audience spécifique dans le jeton de compte de service, indiquez une valeur serviceAccountToken projetée dans le manifeste de pod et définissez sa propriété audience en conséquence. Reportez-vous à la section Pod Manifest Example.

Voici un aperçu du processus d'échange de jetons :

Lorsque vous créez le pod d'application sur le cluster, Kubernetes lui attribue un jeton de compte de service. Le jeton de compte de service inclut l'URL de l'émetteur OIDC du moteur Kubernetes en tant que valeur de la demande iss dans le jeton JWT. Si vous avez spécifié une audience dans le manifeste de pod, l'audience est incluse dans le jeton JWT en tant que valeur de la réclamation aud. Reportez-vous à Exemple de jeton de compte de service.
Le pod d'application envoie une demande à une API sur un fournisseur cloud externe et présente le jeton de compte de service encodé au fournisseur cloud externe dans l'en-tête d'autorisation de la demande d'API.
Le fournisseur d'identités du fournisseur cloud externe décode le jeton de compte de service, extrait l'URL de l'émetteur OIDC du moteur Kubernetes à partir de la demande iss, ajoute /.well-known/openid-configuration à l'URL en tant qu'emplacement du document de repérage OIDC et envoie une demande à cette URL pour obtenir le document de repérage.
L'émetteur OIDC du moteur Kubernetes renvoie le document de repérage OIDC, qui contient l'URL de l'emplacement du JWKS dans le champ jwks_uri. Reportez-vous à la section Discovery Document Example.
Le fournisseur d'identités du fournisseur cloud externe extrait l'URL du document de repérage OIDC et envoie une demande à cette URL pour obtenir le JWKS. Reportez-vous à Exemple JWKS.
Le fournisseur d'identités du fournisseur cloud externe utilise JWKS pour valider le jeton de compte de service présenté à l'origine par le pod d'application.
En supposant que le jeton de compte de service est valide, le fournisseur d'identités du fournisseur cloud externe renvoie un jeton d'accès au pod d'application.
Le pod d'application présente le jeton d'accès à l'API sur le fournisseur cloud externe pour prouver son identité et effectue des demandes d'API.

Le processus d'échange de jetons est présenté dans le diagramme suivant :

Cette image montre le processus d'échange de jetons décrit dans le texte environnant.

Remarques sur le repérage OIDC

Tenez compte des points suivants lors de l'utilisation du repérage OIDC :

Le repérage OIDC est pris en charge sur les clusters exécutant Kubernetes version 1.21 ou ultérieure.
OIDC Discovery est uniquement pris en charge sur les clusters natifs VCN (clusters avec des adresses d'API Kubernetes dans un sous-réseau de votre propre VCN). Reportez-vous à Migration vers des clusters natifs VCN.
Le repérage OIDC est pris en charge sur les noeuds gérés, les noeuds virtuels et les noeuds autogérés.
Le repérage OIDC est pris en charge sur les clusters améliorés (mais pas sur les clusters de base).

Exemple de manifeste de pod, de jeton de compte de service, de document de repérage et de JWKS pour le repérage OIDC

Exemple de manifeste de pod

Exemple de manifeste pour un pod d'application appelant une API de service cloud. Dans cet exemple, le fournisseur d'identités du fournisseur cloud externe attend que le jeton de compte de service indique une audience nommée vault :

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

Exemple de jeton de compte de service

Exemple de jeton de compte de service que Kubernetes peut créer pour le pod dans Exemple de manifeste de pod :

{
  "aud": [
    "vault"
  ],
  "exp": 1731613413,
  "iat": 1700077413,
  "iss": "https://objectstorage.us-ashburn-1.oci.customer-oci.com/n/okecustprod/b/oidc/o/{discoveryUUID}",
  "kubernetes.io": {
    "namespace": "kube-system",
    "node": {
      "name": "127.0.0.1",
      "uid": "58456cb0-dd00-45ed-b797-5578fdceaced"
    },
    "pod": {
      "name": "build-robot-69cbfb9798-jv9gn",
      "uid": "778a530c-b3f4-47c0-9cd5-ab018fb64f33"
    },
    "serviceaccount": {
      "name": "build-robot",
      "uid": "a087d5a0-e1dd-43ec-93ac-f13d89cd13af"
    },
    "warnafter": 1700081020
  },
  "nbf": 1700077413,
  "sub": "system:serviceaccount:kube-system:build-robot"
}

Exemple de document de repérage

Exemple de document de repérage que le moteur Kubernetes peut émettre, y compris l'emplacement du JWKS indiqué par le champ jwks_uri :

{
    "issuer": "https://objectstorage.us-ashburn-1.oci.customer-oci.com/n/okecustprod/b/oidc/o/{discoveryUUID}",
    "jwks_uri": "https://objectstorage.us-ashburn-1.oci.customer-oci.com/n/okecustprod/b/oidc/o/{discoveryUUID}/jwks",
    "response_types_supported": [
        "id_token"
    ],
    "subject_types_supported": [
        "public"
    ],
    "id_token_signing_alg_values_supported": [
        "RS256"
    ]
}

Exemple JWKS

Exemple de JWKS pour authentifier le jeton de compte de service :

{
"keys": [
    {
        "kty": "RSA",
        "kid": "42148Kf",
        "use": "sig",
        "alg": "RS256",
        "n": "iGaLqP6y-SJCCBq5Hv6pGDbG_SQ______asdf3sC",
        "e": "AQAB"
    },
    {
        "kty": "RSA",
        "kid": "bEaunmA",
        "use": "sig",
        "alg": "RS256",
        "n": "BISvILNyn-lUu4goZSXBD9ackM9______RpUlq2w",
        "e": "AQAB"
    }
]
}

Activation d'un cluster pour le repérage OIDC

Pour permettre aux pods d'application exécutés sur un cluster que vous créez avec le moteur Kubernetes de s'authentifier à l'aide du repérage OIDC lors de l'accès aux API hébergées sur un fournisseur cloud externe, vous devez définir la propriété Activer le repérage OIDC du cluster.

Utilisation de la console pour activer un cluster pour le repérage OIDC

Création d'un cluster activé pour le repérage OIDC

Pour créer un cluster et permettre aux pods d'application exécutés sur le cluster de s'authentifier à l'aide du repérage OIDC lors de l'accès aux API hébergées sur un fournisseur cloud externe, procédez comme suit :

Suivez les instructions pour créer un cluster à l'aide du workflow Création personnalisée. Reportez-vous à Utilisation de la console pour créer un cluster avec des paramètres définis explicitement dans le workflow Création personnalisée.
Sur la page de création de cluster, acceptez simplement les détails de configuration par défaut pour le nouveau cluster ou indiquez d'autres options pour les paramètres suivants :
- Nom : nom du nouveau cluster. Acceptez le nom par défaut ou entrez un nom de votre choix. Evitez de saisir des informations confidentielles.
- Compartiment : compartiment dans lequel créer le cluster.
- version de Kubernetes : version de Kubernetes à exécuter sur le noeud de plan du cluster. Acceptez la version par défaut ou sélectionnez la version de votre choix. Entre autres, la version de Kubernetes que vous sélectionnez détermine l'ensemble par défaut des contrôleurs d'admission activés dans le cluster créé (reportez-vous à Contrôleurs d'admission pris en charge).
Sélectionnez Afficher les options avancées et, dans le panneau Découverte OIDC (OpenID Connect), sélectionnez l'option Activer le repérage OIDC.
Entrez d'autres détails de configuration pour le nouveau cluster, comme décrit dans la section Using the Console to create a Cluster with Explicitly Defined Settings in the Custom Create.
Sélectionnez Créer un cluster pour créer ce cluster maintenant.

Modification d'un cluster existant pour activer le repérage OIDC

Pour mettre à jour un cluster existant afin de permettre aux pods d'application exécutés sur le cluster de s'authentifier à l'aide du repérage OIDC lors de l'accès aux API hébergées sur un fournisseur cloud externe, procédez comme suit :

Suivez les instructions pour mettre à jour un cluster existant à l'aide de la console. Reportez-vous à Mise à jour d'un cluster.
Sur la page Détails du cluster, sélectionnez Modifier.
Dans la fenêtre Modifier le cluster, dans le panneau Découverte OIDC (OpenID Connect), sélectionnez l'option Activer le repérage OIDC.
Sélectionnez Enregistrer pour sauvegarder vos modifications.

Utilisation de l'interface de ligne de commande pour activer un cluster pour le repérage OIDC

Pour obtenir des informations sur l'utilisation de l'interface de ligne de commande, reportez-vous à Interface de ligne de commande (CLI). Afin d'obtenir la liste complète des indicateurs et des options disponibles pour les commandes de l'interface de ligne de commande, reportez-vous à Référence de ligne de commande.

Créer un cluster et activer le repérage OIDC

Pour utiliser l'interface de ligne de commande afin de créer un cluster amélioré qui utilise le repérage OIDC pour authentifier les pods d'application lors de l'accès aux API hébergées sur un fournisseur cloud externe, incluez le paramètre --open-id-connect-discovery-enabled dans la commande oci ce cluster create.

Par exemple :

oci ce cluster create \
--compartment-id ocid1.compartment.oc1..aaaaaaaa______n5q \
--name sales \
--vcn-id ocid1.vcn.oc1.phx.aaaaaaaa______lhq \
--type ENHANCED_CLUSTER \
--kubernetes-version v1.25.4 \
--service-lb-subnet-ids "[\"ocid1.subnet.oc1.phx.aaaaaaaa______g7q"]" \
--endpoint-subnet-id ocid1.subnet.oc1.phx.aaaaaaaa______sna \
--endpoint-public-ip-enabled true \
--endpoint-nsg-ids "[\"ocid1.networksecuritygroup.oc1.phx.aaaaaaaa______5qq\"]" \
--cluster-pod-network-options '[{"cniType":"OCI_VCN_IP_NATIVE"}]' \
--open-id-connect-discovery-enabled true

Modification d'un cluster pour activer le repérage OIDC

Pour utiliser l'interface de ligne de commande afin de mettre à jour un cluster amélioré afin d'utiliser le repérage OIDC pour authentifier les pods d'application lors de l'accès aux API hébergées sur un fournisseur cloud externe, définissez l'attribut isOpenIdConnectDiscoveryEnabled sur True :

Dans un éditeur approprié, créez un fichier JSON avec le nom de votre choix (ces instructions supposent que le fichier est appelé cluster-enable-oidc.json) contenant les éléments suivants :
```
{
  "options": {
    "openIdConnectDiscovery": {
      "isOpenIdConnectDiscoveryEnabled": true
    }
  }
}
```
Enregistrez et fermez le fichier cluster-enable-oidc.json.
Mettez à jour le cluster en saisissant la commande suivante :
```
oci ce cluster update --cluster-id <cluster-ocid> --from-json file://<path-to-file>
```
où :
- --cluster-id <cluster-ocid> est l'OCID du cluster dans lequel activer le repérage OIDC.
- --from-json file://<path-to-file> indique l'emplacement du fichier à utiliser lors de la mise à jour du cluster.
Par exemple :
```
oci ce cluster update --cluster-id ocid1.cluster.oc1.iad.aaaaaaaaaf______jrd --from-json file://./cluster-enable-oidc.json
```

Utilisation de l'API pour activer un cluster pour le repérage OIDC

Exécutez l'opération CreateCluster pour créer un cluster, ou l'opération UpdateCluster pour modifier un cluster, et indiquez true comme valeur de l'attribut isOpenIdConnectDiscoveryEnabled de la ressource CreateClusterOptions ou de la ressource UpdateClusterOptionsDetails, respectivement.

Documentation Oracle Cloud Infrastructure