Configuration de politiques pour la création et le déploiement de grappes

Découvrez les politiques IAM à créer avant d'utiliser Kubernetes Engine (OKE).

Lors de la création d'une location, un groupe d'administrateurs est automatiquement créé pour celle-ci dans le service de gestion des identités et des accès de l'OCI (IAM). Les utilisateurs qui sont membres du groupe d'administrateurs peuvent effectuer toutes les opérations possibles sur les ressources de la location. Si tous les utilisateurs qui travailleront avec Kubernetes Engine sont déjà membres du groupe Administrateurs, il n'est pas nécessaire de créer d'autres politiques.

Toutefois, si vous voulez autoriser les utilisateurs qui ne font pas partie du groupe d'administrateur à utiliser Kubernetes Engine, vous devez créer des politiques permettant aux groupes auxquels ces utilisateurs appartiennent d'effectuer des opérations sur les ressources de la location ou sur des compartiments individuels. Certaines politiques sont obligatoires, d'autres sont facultatives. Voir Créer la politique requise pour les groupes et Créer une ou plusieurs politiques supplémentaires pour les groupes.

Vous devez également créer des politiques supplémentaires si vous voulez :

Créez et utilisez des grappes avec des noeuds virtuels et des groupes de noeuds virtuels. Voir Créer une politique pour configurer et utiliser des noeuds virtuels.
Chiffrez les données dans les volumes de démarrage et les volumes par blocs à l'aide de vos propres clés de chiffrement principales du service de chambre forte. Voir Créer une politique pour accéder aux clés de chiffrement gérées par l'utilisateur pour chiffrer les volumes de démarrage, les volumes par blocs ou les systèmes de fichiers.

Si vous voulez que des groupes d'utilisateurs d'une location accèdent aux ressources liées aux grappes dans d'autres locations, vous devez créer des énoncés de politique interlocation spéciaux qui indiquent explicitement les ressources accessibles et partagées. Voir Accès aux ressources liées à une grappe entre des locations.

En plus des politiques ci-dessus gérées par IAM, vous pouvez également utiliser l'approbateur RBAC Kubernetes pour appliquer un contrôle d'accès détaillé supplémentaire aux utilisateurs sur des grappes spécifiques à l'aide de rôles RBAC et de rôles de grappe Kubernetes (voir À propos du contrôle d'accès et du moteur Kubernetes (OKE). Ces règles RBAC Kubernetes contrôlent ce que les utilisateurs authentifiés et les comptes de service peuvent faire dans la grappe, tels que le déploiement de charges de travail ou l'accès à des clés secrètes, à l'aide de l'API Kubernetes.

Notez qu'une politique OCI IAM faisant référence à une source de réseau (telle que allow any-user to use clusters in tenancy where request.networkSource.name='corpnet') ne peut pas être utilisée pour accéder à l'API Kubernetes (par exemple, lors de l'utilisation de kubectl). Pour plus d'informations sur les sources de réseau, voir Présentation des sources de réseau.

Créer la politique requise pour les groupes

Pour créer, mettre à jour et supprimer des grappes et des groupes de noeuds, les utilisateurs qui ne sont pas membres du groupe d'administrateurs doivent disposer des autorisations requises pour travailler avec les ressources des grappes. Pour octroyer aux utilisateurs l'accès requis, vous devez créer une politique contenant plusieurs énoncés obligatoires pour les groupes auxquels ces utilisateurs appartiennent :

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous identité, sélectionnez Politiques. La liste des politiques du compartiment que vous consultez s'affiche.
Sélectionnez le compartiment racine de la location ou un compartiment individuel contenant des ressources de grappe dans la liste de gauche.
Sélectionnez Créer une politique.
Entrez les informations suivantes :
- Nom : Nom de la politique (par exemple, acme-dev-team-oke-required-policy), unique dans le compartiment. Si vous créez la politique dans le compartiment racine de la location, le nom doit être unique parmi toutes les politiques de votre location. Vous ne pourrez pas modifier cet élément ultérieurement. Évitez d'entrer des informations confidentielles.
- Description : Description conviviale. Vous pourrez modifier cet élément ultérieurement si vous le souhaitez.
- État : Les énoncés de politique requis suivants permettent aux utilisateurs d'utiliser Kubernetes Engine pour créer, mettre à jour et supprimer des grappes et des groupes de noeuds :
```
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>
```
  Énoncé de politique requis suivant pour permettre aux utilisateurs d'effectuer toutes les opérations possibles sur les ressources de la grappe (avec cette politique "attrape-tout", tous les utilisateurs deviennent des administrateurs pour les ressources de la grappe) :
```
Allow group <group-name> to manage cluster-family in <location>
```
  Dans les énoncés de politique ci-dessus, remplacez <location> par tenancy (si vous créez la politique dans le compartiment racine de la location) ou compartment <compartment-name> (si vous créez la politique dans un compartiment individuel).
  Note
  
  Notez que, selon le type de grappe, certains énoncés de politique requis peuvent ne pas être nécessaires :
  - Pour utiliser des grappes natives de VCN (où le point d'extrémité de l'API Kubernetes est entièrement intégré à votre VCN), use private-ips est toujours requis. Toutefois, l'énoncé de politique use public-ips n'est nécessaire que si l'option d'adresse IP publique des grappes est sélectionnée. Pour plus d'informations sur les grappes natives du VCN, voir Plan de contrôle de grappe Kubernetes et API Kubernetes.
  - Pour travailler avec des grappes où le point d'extrémité public de l'API Kubernetes se trouve dans une location gérée par Oracle, les énoncés de politique use vnics, use private-ips et use public-ips ne sont pas requis.
  Notez que si un groupe ne se trouve pas dans le domaine d'identité par défaut, ajoutez le préfixe group '<identity-domain-name>'/'group-name' au nom du groupe. Vous pouvez également spécifier un groupe à l'aide de son OCID, dans le format group id <group-ocid>.
- Marqueurs : Si vous êtes autorisé à créer une ressource, vous disposez également des autorisations nécessaires pour appliquer des marqueurs à structure libre à cette ressource. Pour appliquer un marqueur défini, vous devez être autorisé à utiliser l'espace de noms de marqueur. Pour plus d'informations sur le marquage, voir Marqueurs de ressource. Si vous ne savez pas si vous devez appliquer des marqueurs, ignorez cette option ou demandez à un administrateur. Vous pouvez appliquer des marqueurs plus tard.
Sélectionnez Créer.

Créer une ou plusieurs politiques supplémentaires pour les groupes

Pour permettre aux utilisateurs qui ne sont pas membres du groupe d'administration d'utiliser Kubernetes Engine, créez des politiques supplémentaires pour permettre aux groupes auxquels ces utilisateurs appartiennent d'effectuer des opérations sur les ressources de la grappe :

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous identité, sélectionnez Politiques. La liste des politiques du compartiment que vous consultez s'affiche.
Sélectionnez le compartiment racine de la location ou un compartiment individuel contenant des ressources de grappe dans la liste de gauche.
Sélectionnez Créer une politique.
Entrez les informations suivantes :
- Nom : Nom de la politique (par exemple, acme-dev-team-oke-additional-policy), unique dans le compartiment. Si vous créez la politique dans le compartiment racine de la location, le nom doit être unique parmi toutes les politiques de votre location. Vous ne pourrez pas modifier cet élément ultérieurement. Évitez d'entrer des informations confidentielles.
- Description : Description conviviale. Vous pourrez modifier cet élément ultérieurement si vous le souhaitez.
- Énoncé : Énoncé de politique approprié pour permettre aux groupes existants d'effectuer des opérations sur les ressources liées aux grappes. Dans les exemples d'énoncés de politique ci-dessous, remplacez <location> par tenancy (si vous créez la politique dans le compartiment racine de la location) ou compartment <compartment-name> (si vous créez la politique dans un compartiment individuel) :
  - Pour permettre aux utilisateurs du groupe acme-dev-team de créer et de configurer automatiquement de nouvelles ressources de réseau associées lors de la création de grappes dans le flux de création rapide, les politiques doivent également octroyer les autorisations suivantes au groupe :
    - Autorisations VCN_READ et VCN_CREATE. Entrez un énoncé de politique tel que le suivant :
      Allow group acme-dev-team to manage vcns in <location>
    - Autorisations SUBNET_READ et SUBNET_CREATE. Entrez un énoncé de politique tel que le suivant :
      Allow group acme-dev-team to manage subnets in <location>
    - Autorisation INTERNET_GATEWAY_CREATE. Entrez un énoncé de politique tel que le suivant :
      Allow group acme-dev-team to manage internet-gateways in <location>
    - Autorisation NAT_GATEWAY_CREATE. Entrez un énoncé de politique tel que le suivant :
      Allow group acme-dev-team to manage nat-gateways in <location>
    - Autorisation ROUTE_TABLE_UPDATE. Entrez un énoncé de politique tel que le suivant :
      Allow group acme-dev-team to manage route-tables in <location>
    - Autorisation SECURITY_LIST_CREATE. Entrez un énoncé de politique tel que le suivant :
      Allow group acme-dev-team to manage security-lists in <location>
  - Pour permettre aux utilisateurs du groupe acme-dev-team-cluster-viewers de lister simplement les grappes, entrez un énoncé de politique tel que le suivant :
```
Allow group acme-dev-team-cluster-viewers to inspect clusters in <location>
```
  - Pour permettre aux utilisateurs du groupe acme-dev-team-pool-admins de lister, créer, mettre à jour et supprimer des groupes de noeuds, entrez un énoncé de politique tel que le suivant :
```
Allow group acme-dev-team-pool-admins to use cluster-node-pools in <location>
```
  - Pour permettre aux utilisateurs du groupe acme-dev-team-auditors de voir les détails des opérations effectuées sur les grappes, entrez un énoncé de politique tel que le suivant :
```
Allow group acme-dev-team-auditors to read cluster-work-requests in <location>
```
  - Pour permettre aux utilisateurs du groupe acme-dev-team-sgw de créer une passerelle de service afin de permettre aux noeuds de travail d'accéder aux autres ressources de la région sans exposer les données sur le réseau Internet public, entrez un énoncé de politique tel que le suivant :
```
Allow group acme-dev-team-sgw to manage service-gateways in <location>
```
  - Pour permettre aux utilisateurs du groupe acme-dev-team d'accéder aux grappes à l'aide de Cloud Shell, entrez un énoncé de politique tel que le suivant :
```
Allow group acme-dev-team to use cloud-shell in <location>
```
    Notez que pour accéder aux grappes à l'aide de Cloud Shell, vous devrez également configurer le fichier kubeconfig de manière appropriée (voir Configuration de l'accès de Cloud Shell aux grappes). Pour plus d'informations sur Cloud Shell, voir Cloud Shell.
  - Pour permettre aux utilisateurs du groupe acme-dev-team de sélectionner les clés de chiffrement principales et les chambres fortes du service de chambre forte lors de la création et de la modification de grappes à l'aide de la console :
```
Allow group acme-dev-team to read vaults in <location>
```
```
Allow group acme-dev-team to read keys in <location>
```
  - Pour permettre aux utilisateurs du groupe acme-dev-team d'utiliser des réservations de capacité :
```
Allow group acme-dev-team to use compute-capacity-reservations in <location>
```
    Pour plus d'informations, voir Utilisation de réservations de capacité pour provisionner des noeuds gérés
  - Pour permettre aux utilisateurs du groupe acme-dev-team d'utiliser des mesures (par exemple, pour observer la condition des noeuds d'une grappe Kubernetes) :
```
Allow group acme-dev-team to read metrics in <location>
```
    Pour plus d'informations, voir Mesures du moteur Kubernetes (OKE).
  Note
  
  Notez que si un groupe ne se trouve pas dans le domaine d'identité par défaut, ajoutez le préfixe group '<identity-domain-name>'/'group-name' au nom du groupe. Vous pouvez également spécifier un groupe à l'aide de son OCID, dans le format group id <group-ocid>.
- Marqueurs : Si vous êtes autorisé à créer une ressource, vous disposez également des autorisations nécessaires pour appliquer des marqueurs à structure libre à cette ressource. Pour appliquer un marqueur défini, vous devez être autorisé à utiliser l'espace de noms de marqueur. Pour plus d'informations sur le marquage, voir Marqueurs de ressource. Si vous ne savez pas si vous devez appliquer des marqueurs, ignorez cette option ou demandez à un administrateur. Vous pouvez appliquer des marqueurs plus tard.
Sélectionnez Créer.

Créer une politique pour configurer et utiliser des noeuds virtuels

Les utilisateurs administrateurs n'ont pas besoin d'autorisations supplémentaires pour créer et utiliser des grappes avec des noeuds virtuels et des groupes de noeuds virtuels.

Pour permettre aux utilisateurs non administrateurs d'utiliser des noeuds virtuels, vous devez configurer une politique supplémentaire pour accorder à ces utilisateurs les autorisations requises. Pour plus d'informations sur les énoncés de politique à entrer, voir Politiques IAM requises pour l'utilisation des noeuds virtuels.

Créer une politique pour accéder aux clés de chiffrement gérées par l'utilisateur pour chiffrer les volumes de démarrage, les volumes par blocs ou les systèmes de fichiers

Pour spécifier une clé de chiffrement principale gérée par l'utilisateur particulière à partir du service de chambre forte pour chiffrer les données dans les volumes de démarrage, les volumes par blocs ou les systèmes de fichiers, vous devez créer une politique autorisant l'accès à cette clé de chiffrement principale. Pour plus d'informations sur la spécification des clés de chiffrement gérées par l'utilisateur :

pour les volumes de démarrage, 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 et Modification des propriétés de groupe de noeuds et de noeud de travail, le cas échéant.
pour les volumes par blocs, voir Chiffrement des données au repos et des données en transit avec le service de volume par blocs
pour les systèmes de fichiers, voir Chiffrement des données au repos et des données en transit avec le service de stockage de fichiers

Notez que pour pouvoir créer la politique, vous devez connaître l'OCID de la clé de chiffrement principale (voir Gestion des clés).

Pour créer une politique autorisant l'accès à une clé de chiffrement principale gérée par l'utilisateur :

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous identité, sélectionnez Politiques. La liste des politiques du compartiment que vous consultez s'affiche.
Sélectionnez le compartiment racine de la location ou un compartiment individuel contenant des ressources de grappe dans la liste de gauche.
Sélectionnez Créer une politique, suivez les instructions sous Pour créer une politique et donnez un nom à la politique (par exemple, acme-oke-keys-policy).

Pour les volumes de démarrage : Pour utiliser une clé de chiffrement principale du service de chambre forte pour chiffrer les données des volumes de démarrage, entrez les énoncés de politique suivants pour accorder l'accès à la clé de chiffrement principale :

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>'}

où :

<group-name> est un groupe auquel vous appartenez. Notez que si un groupe ne se trouve pas dans le domaine d'identité par défaut, ajoutez le préfixe group '<identity-domain-name>'/'group-name' au nom du groupe. Vous pouvez également spécifier un groupe à l'aide de son OCID, dans le format group id <group-ocid>.
<compartment-name> est le nom du compartiment contenant la clé de chiffrement principale.
<key-OCID> est l'OCID de la clé de chiffrement principale dans le service de chambre forte.

Par exemple :

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'}

Note

Après le 15 août 2024, créez l'énoncé de politique Allow any-user... comme indiqué, à savoir :

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

Notez qu'avant le 15 août 2024, vous deviez définir l'énoncé de politique Allow service oke... suivant :

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

Si un tel énoncé de politique Allow service oke... existe déjà, conservez cet énoncé de politique existant et créez le nouvel énoncé de politique Allow any-user... en plus de l'énoncé de politique existant.

Pour les volumes par blocs : Pour utiliser une clé de chiffrement principale du service de chambre forte pour chiffrer les données des volumes par blocs, entrez des énoncés de politique pour accorder l'accès à la clé de chiffrement principale dans le format suivant :

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>'}