Documentazione dell'infrastruttura Oracle Cloud

Autorizzazione dei pod per accedere alle risorse non OCI mediante la ricerca automatica OpenID Connect (OIDC)

Scopri come utilizzare la ricerca automatica OpenID Connect (OIDC) per autenticare i pod delle applicazioni in esecuzione sui cluster creati con Container Engine for Kubernetes (OKE), in modo che i pod possano chiamare le API dei servizi su provider cloud esterni.

Potresti voler utilizzare pod applicativi in esecuzione su un cluster Kubernetes creato con Kubernetes Engine per comunicare con le API dei servizi cloud ospitate su provider cloud esterni (ad esempio GCP, AWS e Azure). Per garantire la sicurezza delle risorse ospitate da un provider cloud esterno, l'applicazione in esecuzione nel cluster deve autenticare e gestire l'identità. Tuttavia, la gestione diretta delle credenziali può essere un processo complesso per le applicazioni e la rotazione delle chiavi è un processo manuale con un notevole sovraccarico.

OpenID Connect (OIDC) è uno standard di settore per rendere più semplici tali integrazioni. OpenID Connect è un livello di identità creato sopra OAuth 2.0. OpenID Connect supporta un protocollo di ricerca automatica (spesso denominato "OIDC Discovery") che utilizza un documento di configurazione del provider OpenID (noto come "documento di ricerca automatica") per autenticare le applicazioni.

Il motore Kubernetes fornisce il supporto per la ricerca automatica OIDC, consentendoti di creare applicazioni che interagiscono con altri servizi cloud senza la necessità di utilizzare codice fisso e ruotare manualmente le chiavi di autenticazione API. Facoltativamente, puoi abilitare la ricerca automatica OIDC quando crei o aggiorni un cluster avanzato con Kubernetes Engine.

Quando si abilita la ricerca automatica OIDC per un cluster, il token dell'account di servizio dell'applicazione viene autenticato e (se valido) scambiato per un token di accesso. Il token di accesso viene quindi utilizzato per autenticare l'applicazione con l'API nel provider cloud esterno.

Per ulteriori informazioni, consulta la ricerca automatica dell'emittente dell'account di servizio nella documentazione di Kubernetes.

Individuazione OIDC in modo più dettagliato

Kubernetes fornisce un account di servizio a ogni pod dell'applicazione in esecuzione in un cluster e crea un token di account di servizio per ogni account di servizio. Kubernetes gestisce il ciclo di vita dei token degli account di servizio. Il token dell'account di servizio è un token di servizio allegato all'applicazione alle richieste API ed è strutturato come token Web JSON (JWT).

Quando si abilita la ricerca automatica OIDC per un cluster, Kubernetes Engine espone un emittente OIDC e aggiunge l'URL dell'emittente OIDC al token dell'account di servizio come valore della richiesta iss.

La posizione di un documento di ricerca automatica OIDC è relativa all'URL dell'emittente OIDC ed è un endpoint noto pubblicamente accessibile e non autenticato. Il documento di ricerca automatica OIDC include la posizione accessibile pubblicamente e non autenticata di un JWKS (JSON Web Key Set) contenente le chiavi pubbliche per verificare il token dell'account di servizio. Il provider di identità del provider cloud esterno utilizza il documento di ricerca automatica OIDC per individuare JWKS e utilizza JWKS per verificare il token dell'account di servizio.

Per maggiore sicurezza, l'API del servizio cloud richiamata da un pod dell'applicazione potrebbe richiedere la presenza di un determinato pubblico nel token dell'account del servizio creato da Kubernetes. Se l'API del servizio cloud richiede un'audience specifica, è possibile specificare tale audience impostando la proprietà audience di un volume previsto nel file manifesto del pod. L'audience specificata viene inclusa come valore della richiesta aud nel token dell'account di servizio e può quindi essere verificata dal provider cloud esterno. È inoltre possibile specificare un periodo di validità per il token dell'account di servizio impostando il valore della proprietà expirationSeconds del volume previsto nel file manifesto del pod. Per ulteriori informazioni, vedere ServiceAccount proiezione del volume di token nella documentazione di Kubernetes.

Se il provider di identità del provider cloud esterno verifica correttamente il token dell'account di servizio utilizzando JWKS, il provider di identità scambia il token dell'account di servizio per un token di accesso. Il token di accesso viene quindi utilizzato per autenticare l'applicazione e autorizzare l'applicazione a utilizzare l'API nel provider cloud esterno.

Processo di scambio token di ricerca automatica OIDC

Quando si abilita la ricerca automatica OIDC per un cluster in modo che un pod dell'applicazione possa effettuare una richiesta a un'API esterna, Kubernetes Engine espone:
  • Emittente OIDC. L'emittente di OIDC è esposto su HTTPS con un certificato TLS/SSL trusted pubblicamente.
  • JWKS (JSON Web Key Set) contenente le chiavi pubbliche utilizzate per verificare il token dell'account di servizio. JWKS viene memorizzato in un bucket pubblicamente accessibile e non autenticato nel servizio di storage degli oggetti. Vedere Esempio di JWKS.
  • Documento di ricerca automatica OIDC (in formato JSON) che include la posizione del JWKS. Il documento di ricerca automatica viene memorizzato in un bucket pubblicamente accessibile e non autenticato nel servizio di storage degli oggetti. Vedere Esempio di documento di ricerca automatica.

Quando si definisce un pod dell'applicazione che invia richieste a un'interfaccia API esterna, se il provider di identità del provider cloud esterno prevede un'audience specifica nel token dell'account di servizio, specificare un serviceAccountToken previsto nel file manifesto del pod e impostare di conseguenza la proprietà audience. Vedere Esempio di file manifesto del pod.

Di seguito è riportata una panoramica del processo di scambio di token:

  1. Quando crei il pod dell'applicazione sul cluster, Kubernetes fornisce al pod un token di account di servizio. Il token dell'account di servizio include l'URL dell'emittente OIDC del motore Kubernetes come valore della richiesta iss nel JWT. Se è stata specificata un'audience nel file manifesto del pod, l'audience viene inclusa nel file JWT come valore della richiesta aud. Vedere Esempio di token di account di servizio.

  2. Il pod dell'applicazione effettua una richiesta a un'API su un provider cloud esterno e presenta il token dell'account di servizio codificato al provider cloud esterno nell'intestazione di autorizzazione della richiesta API.
  3. Il provider di identità del provider cloud esterno decodifica il token dell'account di servizio, estrae l'URL dell'emittente OIDC di Kubernetes Engine dalla richiesta iss, aggiunge /.well-known/openid-configuration all'URL come posizione del documento di ricerca automatica OIDC e invia una richiesta a tale URL per ottenere il documento di ricerca automatica.
  4. L'emittente OIDC del motore Kubernetes restituisce il documento di ricerca automatica OIDC che contiene l'URL della posizione del JWKS nel campo jwks_uri. Vedere Esempio di documento di ricerca automatica.
  5. Il provider di identità del provider cloud esterno estrae l'URL dal documento di ricerca automatica OIDC e invia una richiesta a tale URL per ottenere JWKS. Vedere Esempio di JWKS.
  6. Il provider di identità del provider cloud esterno utilizza JWKS per convalidare il token dell'account di servizio originariamente presentato dal pod dell'applicazione.
  7. Supponendo che il token dell'account di servizio sia valido, il provider di identità del provider cloud esterno restituisce un token di accesso al pod dell'applicazione.
  8. Il pod dell'applicazione presenta il token di accesso all'API nel provider cloud esterno per dimostrare la propria identità ed effettuare correttamente le richieste API.

Il processo di scambio di token è mostrato nel seguente diagramma:

Questa immagine mostra il processo di scambio di token descritto nel testo circostante.

Note sulla ricerca automatica OIDC

Quando si utilizza la ricerca automatica OIDC, tenere presente quanto riportato di seguito.

  • La ricerca automatica OIDC è supportata nei cluster che eseguono Kubernetes versione 1.21 o successiva.
  • La ricerca automatica OIDC è supportata solo nei cluster nativi della VCN (cluster con endpoint API Kubernetes in una subnet nella propria VCN). Vedere Migrazione a cluster nativi VCN.
  • La ricerca automatica OIDC è supportata su nodi gestiti, nodi virtuali e nodi autogestiti.
  • La ricerca automatica OIDC è supportata sui cluster avanzati (ma non sui cluster di base).

Manifest pod di esempio, token account di servizio, documento di ricerca automatica e JWKS per la ricerca automatica OIDC

Esempio di file manifesto del pod

Manifest di esempio per un pod dell'applicazione che chiama un'API del servizio cloud. In questo esempio il provider di identità del provider cloud esterno prevede che il token dell'account di servizio specifichi un'audience denominata 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

Esempio di token account di servizio

Un token di account di servizio di esempio che Kubernetes potrebbe creare per il pod in Esempio di manifesto del 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"
}

Esempio di documento di ricerca automatica

Un documento di ricerca automatica di esempio che Kubernetes Engine potrebbe emettere, inclusa la posizione del JWKS specificato dal campo 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"
    ]
}

Esempio JWKS

Un esempio di JWKS per autenticare il token dell'account di servizio:

{
"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"
    }
]
}

Abilitazione di un cluster per la ricerca automatica OIDC

Per consentire l'autenticazione dei pod dell'applicazione in esecuzione su un cluster creato con Kubernetes Engine durante l'accesso alle interfacce API ospitate su un provider cloud esterno, è necessario impostare la proprietà Abilita ricerca automatica OIDC del cluster.

Uso della console per abilitare un cluster per la ricerca automatica OIDC

Creazione di un nuovo cluster abilitato per la ricerca automatica OIDC

Per creare un cluster e abilitare i pod dell'applicazione in esecuzione nel cluster per l'autenticazione mediante la ricerca automatica OIDC quando si accede alle interfacce API ospitate in un provider cloud esterno, effettuare le operazioni riportate di seguito.

  1. Seguire le istruzioni per creare un cluster utilizzando il workflow 'Creazione personalizzata'. Vedere Utilizzo della console per creare un cluster con impostazioni definite in modo esplicito nel workflow 'Creazione personalizzata'.

  2. Nella pagina Crea cluster, accettare solo i dettagli di configurazione predefiniti per il nuovo cluster oppure specificare le alternative come indicato di seguito.

    • Nome: il nome del nuovo cluster. Accettare o immettere il nome predefinito desiderato. Evitare di inserire informazioni riservate.
    • Compartimento: il compartimento in cui creare il nuovo cluster.
    • Versione Kubernetes: la versione di Kubernetes da eseguire sui nodi del piano di controllo del cluster. Accettare la versione predefinita o selezionare la versione desiderata. Tra le altre cose, la versione Kubernetes selezionata determina il set predefinito di controller di ammissione attivati nel cluster creato (vedere Controller di ammissione supportati).

  3. Fare clic su Mostra opzioni avanzate e nel pannello Individuazione OpenID Connect (OIDC) selezionare l'opzione Abilita ricerca automatica OIDC.

  4. Immettere altri dettagli di configurazione per il nuovo cluster come descritto in Utilizzo della console per creare un cluster con impostazioni definite in modo esplicito nel workflow 'Creazione personalizzata'.

  5. Fare clic su Crea cluster per creare il nuovo cluster ora.

Modifica di un cluster esistente per abilitare la ricerca automatica OIDC

Per aggiornare un cluster esistente in modo da consentire l'autenticazione dei pod dell'applicazione in esecuzione nel cluster mediante la ricerca automatica OIDC quando si accede alle API ospitate in un provider cloud esterno, effettuare le operazioni riportate di seguito.

  1. Seguire le istruzioni per aggiornare un cluster esistente utilizzando la console. Vedere Aggiornamento di un cluster.

  2. Nella pagina Dettagli cluster fare clic su Modifica.

  3. Nella finestra Modifica cluster, nel pannello Individuazione OpenID Connect (OIDC), selezionare l'opzione Abilita ricerca automatica OIDC.

  4. Fare clic su Salva per salvare le modifiche.

Uso dell'interfaccia CLI per abilitare un cluster per la ricerca automatica OIDC

Per informazioni sull'uso dell'interfaccia CLI, vedere Command Line Interface (CLI). Per un elenco completo dei flag e delle opzioni disponibili per i comandi CLI, vedere il documento Command Line Reference.

Creazione di un cluster e abilitazione della ricerca automatica OIDC

Per utilizzare l'interfaccia CLI per creare un cluster avanzato che utilizza la ricerca automatica OIDC per autenticare i pod dell'applicazione quando si accede alle interfacce API ospitate in un provider cloud esterno, includere il parametro --open-id-connect-discovery-enabled nel comando oci ce cluster create.

Ad esempio: 

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

Modifica di un cluster per abilitare la ricerca automatica OIDC

Per utilizzare l'interfaccia CLI per aggiornare un cluster avanzato in modo da utilizzare la ricerca automatica OIDC per autenticare i pod dell'applicazione quando si accede alle interfacce API ospitate in un provider cloud esterno, impostare l'attributo isOpenIdConnectDiscoveryEnabled su true:

  1. In un editor appropriato, creare un file JSON con il nome desiderato (queste istruzioni presuppongono che il file sia denominato cluster-enable-oidc.json) contenente quanto segue:
    {
  "options": {
    "openIdConnectDiscovery": {
      "isOpenIdConnectDiscoveryEnabled": true
    }
  }
}
  2. Salvare e chiudere il file cluster-enable-oidc.json.

  3. Aggiornare il cluster immettendo:

    oci ce cluster update --cluster-id <cluster-ocid> --from-json file://<path-to-file>

    Dove:

    • --cluster-id <cluster-ocid> è l'OCID del cluster in cui si desidera abilitare la ricerca automatica OIDC.
    • --from-json file://<path-to-file> specifica la posizione del file da utilizzare durante l'aggiornamento del cluster.

    Ad esempio:

    oci ce cluster update --cluster-id ocid1.cluster.oc1.iad.aaaaaaaaaf______jrd --from-json file://./cluster-enable-oidc.json

Uso dell'API per abilitare un cluster per la ricerca automatica OIDC

Eseguire l'operazione CreateCluster per creare un cluster o l'operazione UpdateCluster per modificare un cluster e specificare true come valore dell'attributo isOpenIdConnectDiscoveryEnabled della risorsa CreateClusterOptions o della risorsa UpdateClusterOptionsDetails, rispettivamente.