Configurazione dei criteri per la creazione e la distribuzione del cluster

Scopri i criteri IAM da creare prima di utilizzare Kubernetes Engine (OKE).

Quando si crea una tenancy, viene creato automaticamente un gruppo di amministratori per la tenancy. Gli utenti membri del gruppo Amministratori possono eseguire qualsiasi operazione sulle risorse nella tenancy. Se tutti gli utenti che utilizzeranno Kubernetes Engine sono già membri del gruppo Administrators, non è necessario creare altri criteri.

Tuttavia, se si desidera consentire agli utenti che non sono membri del gruppo di amministratori di utilizzare Kubernetes Engine, è necessario creare criteri per consentire ai gruppi a cui appartengono tali utenti di eseguire operazioni sulle risorse nella tenancy o nei singoli compartimenti. Alcuni criteri sono obbligatori, altri facoltativi. Vedere Crea criterio obbligatorio per i gruppi e Crea uno o più criteri aggiuntivi per i gruppi.

È inoltre necessario creare criteri aggiuntivi se si desidera:

Creare e utilizzare i cluster con nodi virtuali e pool di nodi virtuali. Vedere Crea criterio per impostare e utilizzare nodi virtuali.
Cifrare i dati nei volumi di avvio e nei volumi a blocchi utilizzando le proprie chiavi di cifratura master dal servizio Vault. Vedere Create Policy to Access User-Managed Encryption Keys for Encrypting Boot Volumes, Block Volumes, and/or File Systems.

Se si desidera che gruppi di utenti in una tenancy accedano alle risorse correlate al cluster in altre tenancy, è necessario creare istruzioni speciali dei criteri cross-tenancy che specifichino in modo esplicito le risorse a cui è possibile accedere e condividere. Vedere Accesso alle risorse correlate ai cluster tra tenancy.

Tenere presente che, oltre ai criteri di cui sopra gestiti da IAM, è anche possibile utilizzare l'authorizer RBAC Kubernetes per applicare un controllo dell'accesso con filtro aggiuntivo per gli utenti su cluster specifici tramite ruoli RBAC e clusterroles Kubernetes. Vedere Informazioni sul controllo dell'accesso e sul motore Kubernetes (OKE).

Crea criterio obbligatorio per i gruppi

Per creare, aggiornare ed eliminare cluster e pool di nodi, gli utenti che non sono membri del gruppo Amministratori devono disporre delle autorizzazioni per utilizzare le risorse correlate al cluster. Per concedere agli utenti l'accesso necessario, è necessario creare un criterio con una serie di istruzioni criterio obbligatorie per i gruppi a cui appartengono gli utenti:

Aprire il menu di navigazione e selezionare Identità e sicurezza. In Identità, selezionare Criteri. Viene visualizzata una lista di criteri nel compartimento che si sta visualizzando.
Selezionare il compartimento radice della tenancy o un singolo compartimento contenente risorse correlate al cluster dalla lista a sinistra.
Fare clic su Create Policy.
Immettere quanto riportato di seguito.
- Nome: un nome per il criterio (ad esempio, acme-dev-team-oke-required-policy) univoco all'interno del compartimento. Se si sta creando il criterio nel compartimento radice della tenancy, il nome deve essere univoco in tutti i criteri nella tenancy. Non è possibile modificare in seguito. Evitare di inserire informazioni riservate.
- Descrizione: una descrizione descrittiva. Se lo si desidera, è possibile modificarlo in seguito.
- Dichiarazione: le seguenti istruzioni dei criteri necessarie per consentire agli utenti di utilizzare Kubernetes Engine per creare, aggiornare ed eliminare cluster e pool di nodi:
```
Allow group <group-name> to manage instance-family in <location>
```
```
Allow group <group-name> to use subnets in <location>
```
```
Allow group <group-name> to manage virtual-network-family in <location>
```
```
Allow group <group-name> to inspect compartments in <location>
```
```
Allow group <group-name> to use vnics in <location>
```
```
Allow group <group-name> to use network-security-groups  in <location>
```
```
Allow group <group-name> to use private-ips  in <location>
```
```
Allow group <group-name> to manage public-ips  in <location>
```
```
Allow group <group-name> to manage volume-family in <location>
```
  La seguente istruzione di criterio necessaria per consentire agli utenti di eseguire qualsiasi operazione sulle risorse correlate al cluster (questo criterio 'catch-all' rende in modo efficace tutti gli amministratori degli utenti per quanto riguarda le risorse correlate al cluster):
```
Allow group <group-name> to manage cluster-family in <location>
```
  Nelle istruzioni dei criteri riportate sopra, sostituire <location> con tenancy (se si sta creando il criterio nel compartimento radice della tenancy) o compartment <compartment-name> (se si sta creando il criterio in un singolo compartimento).
  Nota
  
  Si noti che, a seconda del tipo di cluster, alcune istruzioni dei criteri richieste potrebbero non essere necessarie:
  - Per utilizzare i cluster "nativi VCN" (in cui l'endpoint API Kubernetes è completamente integrato con la VCN in uso), è sempre necessario utilizzare use private-ips. Tuttavia, l'istruzione dei criteri use public-ips è necessaria solo se è selezionata l'opzione Indirizzo IP pubblico dei cluster. Per ulteriori informazioni sui cluster nativi della VCN, vedere Piano di controllo cluster Kubernetes e API Kubernetes.
  - Per utilizzare i cluster in cui l'endpoint API Kubernetes pubblico si trova in una tenancy gestita da Oracle, le istruzioni dei criteri use vnics, use private-ips e use public-ips non sono necessarie.
  Si noti che se un gruppo non si trova nel dominio di identità predefinito, inserire il nome del gruppo prima del nome del dominio di identità nel formato group '<identity-domain-name>'/'group-name'. È anche possibile specificare un gruppo utilizzando il relativo OCID, nel formato group id <group-ocid>.
- Tag: se si dispone delle autorizzazioni per creare una risorsa, si dispone anche delle autorizzazioni per applicare tag in formato libero a tale risorsa. Per applicare una tag defined, è necessario disporre delle autorizzazioni per utilizzare la tag namespace. Per ulteriori informazioni sull'applicazione di tag, vedere Tag risorsa. Se non si è certi di applicare le tag, saltare questa opzione o chiedere a un amministratore. È possibile applicare le tag in un secondo momento.
Fare clic su Crea.

Crea uno o più criteri aggiuntivi per i gruppi

Per consentire agli utenti che non sono membri del gruppo di amministratori di utilizzare Kubernetes Engine, creare criteri aggiuntivi per consentire ai gruppi a cui appartengono tali utenti di eseguire operazioni sulle risorse correlate al cluster come indicato di seguito.

Aprire il menu di navigazione e selezionare Identità e sicurezza. In Identità, selezionare Criteri. Viene visualizzata una lista di criteri nel compartimento che si sta visualizzando.
Selezionare il compartimento radice della tenancy o un singolo compartimento contenente risorse correlate al cluster dalla lista a sinistra.
Fare clic su Create Policy.
Immettere quanto riportato di seguito.
- Nome: un nome per il criterio (ad esempio, acme-dev-team-oke-additional-policy) univoco all'interno del compartimento. Se si sta creando il criterio nel compartimento radice della tenancy, il nome deve essere univoco in tutti i criteri nella tenancy. Non è possibile modificare in seguito. Evitare di inserire informazioni riservate.
- Descrizione: una descrizione descrittiva. Se lo si desidera, è possibile modificarlo in seguito.
- Dichiarazione: un'istruzione criterio appropriata per consentire ai gruppi esistenti di eseguire operazioni sulle risorse correlate al cluster. Nelle istruzioni dei criteri di esempio riportate di seguito, sostituire <location> con tenancy (se si sta creando il criterio nel compartimento radice della tenancy) o compartment <compartment-name> (se si sta creando il criterio in un singolo compartimento):
  - Per consentire agli utenti del gruppo acme-dev-team di creare e configurare automaticamente le nuove risorse di rete associate durante la creazione di nuovi cluster nel workflow 'Creazione rapida', i criteri devono inoltre concedere al gruppo:
    - Autorizzazioni VCN_READ e VCN_CREATE. Immettere un'istruzione criterio come:
      Allow group acme-dev-team to manage vcns in <location>
    - Autorizzazioni SUBNET_READ e SUBNET_CREATE. Immettere un'istruzione criterio come:
      Allow group acme-dev-team to manage subnets in <location>
    - Autorizzazione INTERNET_GATEWAY_CREATE. Immettere un'istruzione criterio come:
      Allow group acme-dev-team to manage internet-gateways in <location>
    - Autorizzazione NAT_GATEWAY_CREATE. Immettere un'istruzione criterio come:
      Allow group acme-dev-team to manage nat-gateways in <location>
    - Autorizzazione ROUTE_TABLE_UPDATE. Immettere un'istruzione criterio come:
      Allow group acme-dev-team to manage route-tables in <location>
    - Autorizzazione SECURITY_LIST_CREATE. Immettere un'istruzione criterio come:
      Allow group acme-dev-team to manage security-lists in <location>
  - Per consentire agli utenti del gruppo acme-dev-team-cluster-viewers di elencare semplicemente i cluster, immettere un'istruzione criterio simile alla seguente:
```
Allow group acme-dev-team-cluster-viewers to inspect clusters in <location>
```
  - Per consentire agli utenti del gruppo acme-dev-team-pool-admins di elencare, creare, aggiornare ed eliminare i pool di nodi, immettere un'istruzione dei criteri simile alla seguente:
```
Allow group acme-dev-team-pool-admins to use cluster-node-pools in <location>
```
  - Per consentire agli utenti del gruppo acme-dev-team-auditors di visualizzare i dettagli delle operazioni eseguite sui cluster, immettere un'istruzione criterio simile alla seguente:
```
Allow group acme-dev-team-auditors to read cluster-work-requests in <location>
```
  - Per consentire agli utenti del gruppo acme-dev-team-sgw di creare un gateway di servizi per consentire ai nodi di lavoro di accedere ad altre risorse nella stessa area senza esporre i dati alla rete Internet pubblica, immettere un'istruzione dei criteri simile alla seguente:
```
Allow group acme-dev-team-sgw to manage service-gateways in <location>
```
  - Per consentire agli utenti del gruppo acme-dev-team di accedere ai cluster utilizzando Cloud Shell, immettere un'istruzione criterio simile alla seguente:
```
Allow group acme-dev-team to use cloud-shell in <location>
```
    Tenere presente che per accedere ai cluster utilizzando Cloud Shell, sarà inoltre necessario impostare il file kubeconfig in modo appropriato (vedere Impostazione dell'accesso a Cloud Shell ai cluster). Per ulteriori informazioni su Cloud Shell, vedere Cloud Shell.
  - Per consentire agli utenti del gruppo acme-dev-team di selezionare le chiavi di cifratura principali e i vault nel servizio Vault durante la creazione e la modifica dei cluster mediante la console, effettuare le operazioni riportate di seguito.
```
Allow group acme-dev-team to read vaults in <location>
```
```
Allow group acme-dev-team to read keys in <location>
```
  - Per consentire agli utenti del gruppo acme-dev-team di utilizzare le assegnazioni capacità, effettuare le operazioni riportate di seguito.
```
Allow group acme-dev-team to use compute-capacity-reservations in <location>
```
    Per ulteriori informazioni, vedere Utilizzo delle assegnazioni capacità per il provisioning dei nodi gestiti
  - Per consentire agli utenti del gruppo acme-dev-team di utilizzare le metriche (ad esempio, per osservare la condizione dei nodi in un cluster Kubernetes):
```
Allow group acme-dev-team to read metrics in <location>
```
    Per ulteriori informazioni, consulta le metriche OKE (Kubernetes Engine).
  Nota
  
  Si noti che se un gruppo non si trova nel dominio di identità predefinito, inserire il nome del gruppo prima del nome del dominio di identità nel formato group '<identity-domain-name>'/'group-name'. È anche possibile specificare un gruppo utilizzando il relativo OCID, nel formato group id <group-ocid>.
- Tag: se si dispone delle autorizzazioni per creare una risorsa, si dispone anche delle autorizzazioni per applicare tag in formato libero a tale risorsa. Per applicare una tag defined, è necessario disporre delle autorizzazioni per utilizzare la tag namespace. Per ulteriori informazioni sull'applicazione di tag, vedere Tag risorsa. Se non si è certi di applicare le tag, saltare questa opzione o chiedere a un amministratore. È possibile applicare le tag in un secondo momento.
Fare clic su Crea.

Creare un criterio per impostare e utilizzare i nodi virtuali

Gli utenti amministratore non richiedono autorizzazioni aggiuntive per creare e utilizzare cluster con nodi virtuali e pool di nodi virtuali.

Per consentire agli utenti non amministratori di utilizzare i nodi virtuali, è necessario impostare un criterio aggiuntivo per concedere a tali utenti le autorizzazioni necessarie. Per ulteriori informazioni sulle istruzioni dei criteri da immettere, vedere Criteri IAM obbligatori per l'utilizzo dei nodi virtuali.

Creare un criterio per accedere alle chiavi di cifratura gestite dall'utente per la cifratura dei volumi di avvio, dei volumi a blocchi e/o dei file system

Per specificare una determinata chiave di cifratura master gestita dall'utente dal servizio Vault per cifrare i dati nei volumi di avvio, nei volumi a blocchi e/o nei file system, è necessario creare un criterio per consentire l'accesso a tale chiave di cifratura master. Per ulteriori informazioni sulla specifica delle chiavi di cifratura gestite dall'utente, effettuare le operazioni riportate di seguito.

per i volumi di avvio, vedere Utilizzo della console per creare un cluster con impostazioni definite in modo esplicito nel workflow 'Creazione personalizzata' e Modifica delle proprietà del pool di nodi e del nodo di lavoro a seconda dei casi.
per i volumi a blocchi, vedere Cifratura dei dati in archivio e dei dati in transito con il servizio per volumi a blocchi
per i file system, vedere Cifratura dei dati in archivio e dei dati in transito con il servizio di storage di file

Prima di poter creare il criterio, è necessario conoscere l'OCID della chiave di cifratura principale (vedere Gestione delle chiavi).

Per creare un criterio per consentire l'accesso a una chiave di cifratura master gestita dall'utente, effettuare le operazioni riportate di seguito.

Aprire il menu di navigazione e selezionare Identità e sicurezza. In Identità, selezionare Criteri. Viene visualizzata una lista di criteri nel compartimento che si sta visualizzando.
Viene visualizzata una lista di criteri nel compartimento che si sta visualizzando.
Selezionare il compartimento radice della tenancy o un singolo compartimento contenente risorse correlate al cluster dalla lista a sinistra.
Fare clic su Crea criterio, seguire le istruzioni in Per creare un criterio e assegnare un nome al criterio, ad esempio acme-oke-keys-policy.

Per i volumi di avvio: per utilizzare una chiave di cifratura master dal servizio Vault per cifrare i dati nei volumi di avvio, immettere le istruzioni dei criteri riportate di seguito per concedere l'accesso alla chiave di cifratura master.

Allow group <group-name> to read keys in compartment <compartment-name> where target.key.id = '<key_OCID>'


Allow service oke to use key-delegates in compartment <compartment-name> where target.key.id = '<key_OCID>'


Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key_OCID>'


Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type='nodepool', target.key.id = '<key_OCID>'}

Dove:

<group-name> è un gruppo a cui si appartiene. Si noti che se un gruppo non si trova nel dominio di identità predefinito, inserire il nome del gruppo prima del nome del dominio di identità nel formato group '<identity-domain-name>'/'group-name'. È anche possibile specificare un gruppo utilizzando il relativo OCID, nel formato group id <group-ocid>.
<compartment-name> è il nome del compartimento contenente la chiave di cifratura master.
<key-OCID> è l'OCID della chiave di cifratura master nel vault.

Ad esempio:

Allow group acme-dev-team to read keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
Allow service oke to use key-delegates in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
Allow service blockstorage to use keys in compartment acme-kms-key-compartment where target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'
Allow any-user to use key-delegates in compartment acme-kms-key-compartment where ALL {request.principal.type='nodepool', target.key.id = 'ocid1.key.oc1.iad.anntl______usjh'}

Nota

Dopo il 15 agosto 2024, creare la dichiarazione dei criteri Allow any-user... come mostrato, vale a dire:

Allow any-user to use key-delegates in <compartment-name> where ALL {request.principal.type='nodepool', target.key.id = '<key_OCID>'}

Si noti che prima del 15 agosto 2024 era necessario definire la seguente istruzione dei criteri Allow service oke...:

Allow service oke to use key-delegates in compartment <compartment-name> where target.key.id = '<key_OCID>'

Se un'istruzione criterio Allow service oke... esiste già, conservare questa istruzione criterio esistente e creare la nuova istruzione criterio Allow any-user... oltre all'istruzione criterio esistente.

Per i volumi a blocchi: per utilizzare una chiave di cifratura master dal servizio Vault per cifrare i dati nei volumi a blocchi, immettere le istruzioni dei criteri per concedere l'accesso alla chiave di cifratura master nel formato seguente:

Allow service blockstorage to use keys in compartment <compartment-name> where target.key.id = '<key-ocid>'


Allow any-user to use key-delegates in compartment <compartment-name> where ALL {request.principal.type = 'cluster', target.key.id = '<key-ocid>'}