Configuration de stratégies pour la création et le déploiement de clusters

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

Lorsqu'une location est créée, un groupe d'administrateurs est automatiquement créé pour cette location dans OCI Identity and Access Management (IAM). Les utilisateurs membres du groupe d'administrateurs peuvent effectuer n'importe quelle opération sur les ressources de la location. Si tous les utilisateurs qui vont travailler avec Kubernetes Engine sont déjà membres du groupe d'administrateurs, il n'est pas nécessaire de créer d'autres stratégies.

Toutefois, si vous voulez permettre aux utilisateurs qui ne sont pas membres du groupe d'administrateurs d'utiliser Kubernetes Engine, vous devez créer des stratégies permettant aux groupes auxquels appartiennent ces utilisateurs d'effectuer des opérations sur les ressources de la location ou de compartiments individuels. Certaines stratégies sont requises, d'autres sont facultatives. Reportez-vous à Création de la stratégie requise pour les groupes et à Création de stratégies supplémentaires pour les groupes.

Vous devez également créer des stratégies supplémentaires si vous souhaitez :

Créer et utiliser des clusters avec des noeuds virtuels et des pools de noeuds virtuels. Reportez-vous à Création d'une stratégie pour configurer et utiliser des noeuds virtuels.
Chiffrez les données dans les volumes d'initialisation et les volumes de blocs à l'aide de vos propres clés de cryptage maître à partir du service Vault. Reportez-vous à Création d'une stratégie pour accéder aux clés de cryptage gérées par l'utilisateur pour le cryptage de volumes d'initialisation, de volumes de blocs et/ou de systèmes de fichiers.

Si vous voulez que les groupes d'utilisateurs d'une location accèdent aux ressources liées au cluster dans d'autres locations, vous devez créer des instructions de stratégie inter-locations spéciales qui indiquent explicitement les ressources accessibles et partagées. Reportez-vous à Accès aux ressources liées au cluster dans les locations.

Outre les stratégies ci-dessus gérées par IAM, vous pouvez également utiliser le donneur d'accès RBAC Kubernetes pour appliquer un contrôle d'accès détaillé supplémentaire aux utilisateurs sur des clusters spécifiques à l'aide des rôles et des rôles de cluster RBAC Kubernetes (reportez-vous à A 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 le cluster, comme le déploiement de charges globales ou l'accès aux clés secrètes, à l'aide de l'API Kubernetes.

Une stratégie OCI IAM qui fait référence à une source 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 réseau, reportez-vous à Introduction aux sources réseau.

Création de la stratégie requise pour les groupes

Pour créer, mettre à jour et supprimer des clusters ainsi que des pools de noeuds, les utilisateurs non membres du groupe d'administrateurs doivent disposer des droits d'accès requis pour utiliser des ressources de cluster. Afin d'accorder aux utilisateurs l'accès requis, vous devez créer une stratégie comportant plusieurs instructions de stratégie requises pour les groupes auxquels ils appartiennent :

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Identité, sélectionnez Stratégies. La liste des stratégies du compartiment en cours de visualisation apparaît.
Sélectionnez le compartiment racine de la location ou un compartiment individuel contenant les ressources liées au cluster dans la liste à gauche.
Sélectionnez Créer une stratégie.
Entrez les informations suivantes :
- Nom : nom de la stratégie (par exemple, acme-dev-team-oke-required-policy). Le nom doit être unique dans le compartiment. Si vous créez la stratégie dans le compartiment racine de la location, le nom doit être unique dans toutes les stratégies de la location. Vous ne pourrez pus modifier ce paramètre par la suite. Evitez de saisir des informations confidentielles.
- Description : description conviviale. Vous pourrez modifier ce paramètre ultérieurement si vous le souhaitez.
- Instruction : instructions de stratégie requises suivantes permettant aux utilisateurs d'utiliser le moteur Kubernetes pour créer, mettre à niveau et supprimer les clusters et les pools 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>
```
  L'instruction de stratégie requise suivante permet aux utilisateurs d'effectuer n'importe quelle opération sur les ressources liées au cluster (cette stratégie de détection générique transforme tous les utilisateurs en administrateurs dès que des ressources de cluster sont concernées) :
```
Allow group <group-name> to manage cluster-family in <location>
```
  Dans les instructions de stratégie ci-dessus, remplacez <location> par tenancy (si vous créez la stratégie dans le compartiment racine de la location) ou par compartment <compartment-name> (si vous créez la stratégie dans un compartiment individuel).
  Remarque
  
  Selon le type de cluster, certaines instructions de stratégie requises peuvent ne pas être nécessaires :
  - Pour utiliser des clusters natifs VCN (où l'adresse d'API Kubernetes est entièrement intégrée à votre VCN), use private-ips est toujours requis. Toutefois, l'instruction de stratégie use public-ips n'est nécessaire que si l'option d'adresse IP publique des clusters est sélectionnée. Pour plus d'informations sur les clusters natifs du réseau cloud virtuel, reportez-vous à Plan de contrôle de cluster Kubernetes et API Kubernetes.
  - Pour utiliser des clusters où l'adresse d'API Kubernetes publique se trouve dans une location gérée par Oracle, les instructions de stratégie use vnics, use private-ips et use public-ips sont inutiles.
  Si un groupe ne se trouve pas dans le domaine d'identité par défaut, ajoutez un préfixe au nom de domaine d'identité au format group '<identity-domain-name>'/'group-name'. Vous pouvez également indiquer un groupe à l'aide de son OCID, au format group id <group-ocid>.
- Balises : si vous disposez des droits d'accès nécessaires pour créer une ressource, vous disposez également de droits d'accès nécessaires pour lui appliquer des balises à format libre. Pour appliquer une balise defined, vous devez disposer des droits d'accès permettant d'utiliser l'espace de noms de balise. Pour plus d'informations sur le balisage, reportez-vous à Balises de ressource. Si vous n'êtes pas certain d'appliquer des balises, ignorez cette option ou demandez à un administrateur. Vous pouvez appliquer des balises ultérieurement.
Choisissez Créer.

Création de stratégies supplémentaires pour les groupes

Pour permettre aux utilisateurs qui ne sont pas membres du groupe d'administrateurs d'utiliser Kubernetes Engine, créez des stratégies supplémentaires permettant aux groupes auxquels appartiennent ces utilisateurs d'effectuer des opérations sur les ressources liées au cluster comme suit :

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Identité, sélectionnez Stratégies. La liste des stratégies du compartiment en cours de visualisation apparaît.
Sélectionnez le compartiment racine de la location ou un compartiment individuel contenant les ressources liées au cluster dans la liste à gauche.
Sélectionnez Créer une stratégie.
Entrez les informations suivantes :
- Nom : nom de la stratégie (par exemple, acme-dev-team-oke-additional-policy). Le nom doit être unique dans le compartiment. Si vous créez la stratégie dans le compartiment racine de la location, le nom doit être unique dans toutes les stratégies de la location. Vous ne pourrez pus modifier ce paramètre par la suite. Evitez de saisir des informations confidentielles.
- Description : description conviviale. Vous pourrez modifier ce paramètre ultérieurement si vous le souhaitez.
- Instruction : instruction de stratégie adéquate permettant aux groupes existants d'effectuer des opérations sur les ressources de cluster. Dans les exemples d'instructions de stratégie ci-dessous, remplacez <location> par tenancy (si vous créez la stratégie dans le compartiment racine de la location) ou par compartment <compartment-name> (si vous créez la stratégie dans un compartiment individuel) :
  - Pour permettre aux utilisateurs du groupe acme-dev-team de créer et de configurer automatiquement des ressources réseau associées lors de la création de clusters dans le workflow Création rapide, les stratégies doivent également octroyer les droits d'accès suivants au groupe :
    - Droits d'accès VCN_READ et VCN_CREATE. Entrez une instruction de stratégie comme suit :
      Allow group acme-dev-team to manage vcns in <location>
    - Droits d'accès SUBNET_READ et SUBNET_CREATE. Entrez une instruction de stratégie comme suit :
      Allow group acme-dev-team to manage subnets in <location>
    - Droit d'accès INTERNET_GATEWAY_CREATE. Entrez une instruction de stratégie comme suit :
      Allow group acme-dev-team to manage internet-gateways in <location>
    - Droit d'accès NAT_GATEWAY_CREATE. Entrez une instruction de stratégie comme suit :
      Allow group acme-dev-team to manage nat-gateways in <location>
    - Droit d'accès ROUTE_TABLE_UPDATE. Entrez une instruction de stratégie comme suit :
      Allow group acme-dev-team to manage route-tables in <location>
    - Droit d'accès SECURITY_LIST_CREATE. Entrez une instruction de stratégie comme suit :
      Allow group acme-dev-team to manage security-lists in <location>
  - Pour permettre aux utilisateurs du groupe acme-dev-team-cluster-viewers de simplement répertorier les clusters, entrez une instruction de stratégie semblable à la suivante :
```
Allow group acme-dev-team-cluster-viewers to inspect clusters in <location>
```
  - Pour permettre aux utilisateurs du groupe acme-dev-team-pool-admins de répertorier, de créer, de mettre à jour et de supprimer des pools de noeuds, entrez une instruction de stratégie semblable à la suivante :
```
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 visualiser les détails des opérations effectuées sur les clusters, entrez une instruction de stratégie semblable à la suivante :
```
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 d'autoriser les noeuds de processus actif à accéder à d'autres ressources situées dans la même région sans rendre les données visibles sur le réseau Internet public, entrez une instruction de stratégie semblable à la suivante :
```
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 clusters à l'aide de Cloud Shell, entrez une instruction de stratégie semblable à la suivante :
```
Allow group acme-dev-team to use cloud-shell in <location>
```
    Pour accéder aux clusters à l'aide de Cloud Shell, vous devez également configurer correctement le fichier kubeconfig (reportez-vous à Configuration de l'accès de Cloud Shell aux clusters). Pour plus d'informations sur Cloud Shell, reportez-vous à Cloud Shell.
  - Pour permettre aux utilisateurs du groupe acme-dev-team de sélectionner des clés de cryptage maître et des coffres dans le service Vault lors de la création et de la modification de clusters à l'aide de la console, procédez comme suit :
```
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 les réservations de capacité, procédez comme suit :
```
Allow group acme-dev-team to use compute-capacity-reservations in <location>
```
    Pour plus d'informations, reportez-vous à 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 dans un cluster Kubernetes), procédez comme suit :
```
Allow group acme-dev-team to read metrics in <location>
```
    Pour plus d'informations, reportez-vous à Mesures de Kubernetes Engine (OKE).
  Remarque
  
  Si un groupe ne se trouve pas dans le domaine d'identité par défaut, ajoutez un préfixe au nom de domaine d'identité au format group '<identity-domain-name>'/'group-name'. Vous pouvez également indiquer un groupe à l'aide de son OCID, au format group id <group-ocid>.
- Balises : si vous disposez des droits d'accès nécessaires pour créer une ressource, vous disposez également de droits d'accès nécessaires pour lui appliquer des balises à format libre. Pour appliquer une balise defined, vous devez disposer des droits d'accès permettant d'utiliser l'espace de noms de balise. Pour plus d'informations sur le balisage, reportez-vous à Balises de ressource. Si vous n'êtes pas certain d'appliquer des balises, ignorez cette option ou demandez à un administrateur. Vous pouvez appliquer des balises ultérieurement.
Choisissez Créer.

Créer une stratégie pour configurer et utiliser des noeuds virtuels

Les administrateurs n'ont pas besoin de droits d'accès supplémentaires pour créer et utiliser des clusters avec des noeuds virtuels et des pools de noeuds virtuels.

Pour permettre aux utilisateurs non administrateurs d'utiliser des noeuds virtuels, vous devez configurer une stratégie supplémentaire afin de leur accorder les droits d'accès requis. Pour plus d'informations sur les instructions de stratégie à entrer, reportez-vous à Stratégies IAM requises pour l'utilisation des noeuds virtuels.

Création d'une stratégie pour accéder aux clés de cryptage gérées par l'utilisateur pour le cryptage des volumes d'initialisation, des volumes de blocs et/ou des systèmes de fichiers

Pour indiquer une clé de cryptage maître gérée par l'utilisateur à partir du service Vault afin de crypter les données dans les volumes d'initialisation, les volumes de blocs et/ou les systèmes de fichiers, vous devez créer une stratégie permettant d'autoriser l'accès à cette clé de cryptage maître. Pour plus d'informations sur la spécification de clés de cryptage gérées par l'utilisateur, procédez comme suit :

pour plus d'informations sur les volumes d'initialisation, reportez-vous aux sections Using the Console to create a Cluster with Explicitly Defined Settings in the Custom Create et Modifying Node Pool and Worker Node Properties, le cas échéant.
pour les volumes de blocs, reportez-vous à Cryptage des données inactives et en transit avec Block Volume Service
pour les systèmes de fichiers, reportez-vous à Cryptage des données au repos et des données en transit avec le service File Storage

Pour pouvoir créer la stratégie, vous devez connaître l'OCID de la clé de cryptage maître (reportez-vous à Gestion des clés).

Pour créer une stratégie autorisant l'accès à une clé de cryptage maître gérée par l'utilisateur, procédez comme suit :

Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Identité, sélectionnez Stratégies. La liste des stratégies du compartiment en cours de visualisation apparaît.
Sélectionnez le compartiment racine de la location ou un compartiment individuel contenant les ressources liées au cluster dans la liste à gauche.
Sélectionnez Créer une stratégie et donnez un nom à la stratégie (par exemple, acme-oke-keys-policy) en suivant les instructions fournies dans Procédure d'établissement d'une stratégie.

Pour les volumes d'initialisation : pour utiliser une clé de cryptage maître du service Vault afin de crypter les données des volumes d'initialisation, entrez les instructions de stratégie suivantes afin d'accorder l'accès à la clé de cryptage maître :

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. Si un groupe ne se trouve pas dans le domaine d'identité par défaut, ajoutez un préfixe au nom de domaine d'identité au format group '<identity-domain-name>'/'group-name'. Vous pouvez également indiquer un groupe à l'aide de son OCID, au format group id <group-ocid>.
<compartment-name> est le nom du compartiment contenant la clé de cryptage maître.
<key-OCID> est l'OCID de la clé de cryptage maître dans Vault.

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

Remarque

Après le 15 août 2024, créez l'instruction de stratégie 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>'}

Avant le 15 août 2024, vous deviez définir l'instruction de stratégie Allow service oke... suivante :

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

Si une telle instruction de stratégie Allow service oke... existe déjà, conservez cette instruction de stratégie existante et créez la nouvelle instruction de stratégie Allow any-user... en plus de l'instruction de stratégie existante.

Pour les volumes de blocs : pour utiliser une clé de cryptage maître du service Vault afin de crypter les données dans les volumes de blocs, entrez des instructions de stratégie afin d'accorder l'accès à la clé de cryptage maître au 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>'}