Autorisation aux pods d'accéder aux ressources non OCI à l'aide de la détection OpenID Connect (OIDC)
Découvrez comment utiliser la fonction de détection OpenID Connect (OIDC) pour authentifier les pods d'application s'exécutant sur des grappes que vous créez avec Container Engine pour Kubernetes (OKE), afin que les pods puissent appeler les API de service sur des fournisseurs de nuage externes.
Vous voudrez peut-être que les pods d'application s'exécutent sur une grappe Kubernetes que vous avez créée avec Kubernetes Engine pour communiquer avec les API de service en nuage hébergées sur des fournisseurs de nuage externes (tels que GCP, AWS et Azure). Pour assurer la sécurité des ressources hébergées par un fournisseur de services en nuage externe, l'application exécutée sur la grappe doit s'authentifier et gérer l'identité. Cependant, la gestion directe des informations d'identification et de connexion 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 sectorielle permettant de simplifier ces intégrations. OpenID Connect est une couche d'identité basée sur la version OAuth 2.0. OpenID Connect prend en charge un protocole de détection (souvent appelé "découverte OIDC") qui utilise un document de configuration de fournisseur OpenID (appelé "document de détection") pour authentifier les applications.
Kubernetes Engine prend en charge la détection d'OIDC, ce qui vous permet de créer des applications qui interagissent avec d'autres services en nuage sans avoir à coder dur et à effectuer la rotation manuelle des clés d'authentification d'API. Vous pouvez éventuellement activer la détection OIDC lorsque vous créez ou mettez à jour une grappe améliorée avec Kubernetes Engine.
Au niveau général, lorsque vous activez la détection OIDC pour une grappe, le jeton de compte de service de l'application est authentifié et (le cas échéant) échangé contre un jeton d'accès. Le jeton d'accès est ensuite utilisé pour authentifier l'application avec l'API du fournisseur de services en nuage externe.
Pour plus d'informations, voir Détection d'émetteur de compte de service dans la documentation sur Kubernetes.
Découverte d'OIDC plus en détail
Kubernetes donne un compte de service à chaque pod d'application s'exécutant sur une grappe 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 porteur que l'application attache aux demandes d'API et structuré en tant que jeton Web JSON (JWT).
Lorsque vous activez la détection OIDC pour une grappe, le moteur Kubernetes expose un émetteur OIDC et ajoute l'URL de l'émetteur OIDC au jeton du compte de service en tant que valeur de la réclamation iss.
L'emplacement d'un document de détection OIDC est relatif à l'URL de l'émetteur OIDC et est un point d'extrémité bien connu, accessible au public et non authentifié. Le document de détection OIDC inclut l'emplacement accessible publiquement et non authentifié d'un jeu de clés Web JSON (JWKS) qui contient les clés publiques pour vérifier le jeton de compte de service. Le fournisseur d'identités du fournisseur de services en nuage externe utilise le document de détection OIDC pour localiser JWKS et utilise JWKS pour vérifier le jeton du compte de service.
Pour plus de sécurité, l'API de service en nuage appelée par un pod d'application peut nécessiter la présence d'un public particulier dans le jeton de compte de service créé par Kubernetes. Si l'API du service en nuage nécessite un public particulier, vous pouvez spécifier ce public en définissant la propriété audience d'un volume projeté dans le manifeste de pod. Le public que vous spécifiez est inclus en tant que valeur de la réclamation aud dans le jeton de compte de service et peut ensuite être vérifié par le fournisseur de services en nuage 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, voir Projection de volume de jeton ServiceAccount dans la documentation sur Kubernetes.
Si le fournisseur d'identités du fournisseur de services en nuage externe vérifie le jeton du compte de service à l'aide de JWKS, le fournisseur d'identités échange le jeton du compte de service contre un jeton d'accès. Le jeton d'accès est ensuite utilisé pour authentifier l'application et autoriser celle-ci à utiliser l'API du fournisseur de services en nuage externe.
Processus d'échange de jeton OIDC Discovery
- Émetteur OIDC. L'émetteur OIDC est exposé sur HTTPS avec un certificat TLS/SSL approuvé publiquement.
- Jeu de clés Web JSON (JWKS), contenant les clés publiques utilisées pour vérifier le jeton du compte de service. Le service JWKS est stocké dans un seau accessible publiquement et non authentifié dans le service de stockage d'objets. Voir Exemple JWKS.
- Document de détection OIDC (au format JSON) qui inclut l'emplacement du JWKS. Le document de détection est stocké dans un seau accessible publiquement et non authentifié dans le service de stockage d'objets. Voir Exemple de document de découverte.
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 services en nuage externe attend un public spécifique dans le jeton de compte de service, spécifiez une projection de serviceAccountToken dans le manifeste du pod et définissez sa propriété audience en conséquence. Voir Exemple de manifeste de pod.
Voici un aperçu du processus d'échange de jetons :
-
Lorsque vous créez le pod d'application sur la grappe, Kubernetes lui donne un jeton de compte de service. Le jeton de compte de service inclut l'URL de l'émetteur OIDC du moteur Kubernetes comme valeur de la revendication
issdans le JWT. Si vous avez spécifié une audience dans le manifeste de pod, elle est incluse dans JWT en tant que valeur de la revendicationaud. Voir Exemple de jeton de compte de service. - Le module de réseautage d'application fait une demande à une API sur un fournisseur de services en nuage externe et présente le jeton de compte de service encodé au fournisseur de services en nuage externe dans l'en-tête d'autorisation de la demande d'API.
- Le fournisseur d'identités du fournisseur de services en nuage externe décode le jeton de compte de service, extrait l'URL de l'émetteur OIDC du moteur Kubernetes de la revendication
iss, ajoute/.well-known/openid-configurationà l'URL en tant qu'emplacement du document de détection OIDC et envoie une demande à cette URL pour obtenir le document de détection. - L'émetteur OIDC du moteur Kubernetes retourne le document de détection OIDC, qui contient l'URL de l'emplacement du JWKS dans le champ
jwks_uri. Voir Exemple de document de découverte. - Le fournisseur d'identités du fournisseur de services en nuage externe extrait l'URL du document de détection OIDC et envoie une demande à cette URL pour obtenir JWKS. Voir Exemple JWKS.
- Le fournisseur d'identités du fournisseur de services en nuage externe utilise JWKS pour valider le jeton de compte de service initialement présenté par le pod d'application.
- En supposant que le jeton de compte de service est valide, le fournisseur d'identités du fournisseur de services en nuage externe retourne un jeton d'accès au pod d'application.
- Le module de réseautage d'application présente le jeton d'accès à l'API du fournisseur de services en nuage externe pour prouver son identité et effectue des demandes d'API avec succès.
Le diagramme suivant illustre le processus d'échange de jetons :
Notes sur la détection OIDC
Notez les points suivants lors de l'utilisation d'OIDC Discovery :
- La détection OIDC est prise en charge sur les grappes exécutant Kubernetes version 1.21 ou ultérieure.
- La détection OIDC n'est prise en charge que sur les grappes natives du VCN (grappes avec des points d'extrémité d'API Kubernetes dans un sous-réseau de votre propre VCN). Voir Migration vers des grappes natives de VCN.
- La détection OIDC est prise en charge sur les noeuds gérés, les noeuds virtuels et les noeuds autogérés.
- La détection OIDC est prise en charge sur les grappes améliorées (mais pas sur les grappes de base).
Exemple de manifeste de pod, jeton de compte de service, document de détection et JWKS pour la détection OIDC
Exemple de manifeste de pod
Exemple de manifeste pour un pod d'application appelant une API de service en nuage. Dans cet exemple, le fournisseur d'identités du fournisseur de services en nuage externe s'attend à ce que le jeton de compte de service spécifie un public nommé 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: vaultExemple 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 d'exploration
Exemple de document de détection que le moteur Kubernetes peut émettre, y compris l'emplacement du JWKS spécifié 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'une grappe pour la détection OIDC
Pour permettre aux pods d'application exécutés sur une grappe que vous créez à l'aide de Kubernetes Engine de s'authentifier à l'aide de la détection OIDC lors de l'accès aux API hébergées sur un fournisseur de nuage externe, vous devez définir la propriété Activer la détection OIDC de la grappe.
Utilisation de la console pour activer une grappe pour la détection OIDC
Création d'une nouvelle grappe activée pour la détection OIDC
Pour créer une grappe et permettre aux pods d'application s'exécutant sur la grappe de s'authentifier à l'aide de OIDC Discovery lors de l'accès aux API hébergées sur un fournisseur de services en nuage externe :
- Suivez les instructions pour créer une grappe à l'aide du flux de création personnalisée. Voir Utilisation de la console pour créer une grappe avec des paramètres définis explicitement dans le flux de création personnalisée.
-
Dans la page Créer une grappe, acceptez simplement les détails de configuration par défaut pour la nouvelle grappe ou spécifiez-en d'autres comme suit :
- Nom : Nom de la nouvelle grappe. Acceptez le nom par défaut ou entrez un nom de votre choix. Évitez d'entrer des informations confidentielles.
- Compartiment : Compartiment dans lequel créer la nouvelle grappe.
- Version de Kubernetes : Version de Kubernetes à exécuter sur les noeuds de plan de contrôle de la grappe. Acceptez la version par défaut ou sélectionnez une version de votre choix. La version de Kubernetes que vous sélectionnez détermine notamment le jeu de contrôleurs d'admission par défaut activé dans la grappe créée (voir Contrôleurs d'admission pris en charge).
-
Sélectionnez Afficher les options avancées et dans le panneau Détection OpenID Connect (OIDC), sélectionnez l'option Activer la détection OIDC.
- Entrez d'autres détails de configuration pour la nouvelle grappe, comme décrit dans Utilisation de la console pour créer une grappe avec des paramètres définis explicitement dans le flux de création personnalisée.
-
Sélectionnez Créer une grappe pour créer la grappe maintenant.
Modification d'une grappe existante pour activer la détection OIDC
Pour mettre à jour une grappe existante afin de permettre aux pods d'application exécutés sur la grappe de s'authentifier à l'aide de OIDC Discovery lors de l'accès aux API hébergées sur un fournisseur de services en nuage externe :
- Suivez les instructions pour mettre à jour une grappe existante à l'aide de la console. Voir Mise à jour d'une grappe.
-
Dans la page Détails de la grappe, sélectionnez Modifier.
-
Dans la fenêtre Modifier la grappe, dans le panneau Détection OpenID Connect (OIDC), sélectionnez l'option Activer la détection OIDC.
-
Sélectionnez Enregistrer pour enregistrer vos modifications.
Utilisation de l'interface de ligne de commande pour activer une grappe pour la détection OIDC
Pour des informations sur l'utilisation de l'interface de ligne de commande, voir Interface de ligne de commande. Pour une liste complète des indicateurs et les options disponibles pour les commandes de l'interface de ligne de commande, voir Informations de référence sur la ligne de commande.
Créer une grappe et activer la détection OIDC
Pour utiliser l'interface de ligne de commande pour créer une grappe améliorée qui utilise la détection OIDC pour authentifier les pods d'application lors de l'accès aux API hébergées sur un fournisseur de nuage 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 trueModification d'une grappe pour activer la détection OIDC
Pour utiliser l'interface de ligne de commande pour mettre à jour une grappe améliorée afin d'utiliser OIDC Discovery pour authentifier les pods d'application lors de l'accès aux API hébergées sur un fournisseur de services en nuage externe, réglez l'attribut isOpenIdConnectDiscoveryEnabled à Vrai :
- 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 la grappe en entrant :
oci ce cluster update --cluster-id <cluster-ocid> --from-json file://<path-to-file>où :
--cluster-id <cluster-ocid>est l'OCID de la grappe dans laquelle vous voulez activer la détection OIDC.--from-json file://<path-to-file>indique l'emplacement du fichier à utiliser lors de la mise à jour de la grappe.
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 une grappe pour la détection OIDC
Exécutez l'opération CreateCluster pour créer une grappe ou l'opération UpdateCluster pour modifier une grappe, et spécifiez true comme valeur de l'attribut isOpenIdConnectDiscoveryEnabled