Préalables au déploiement du contrôleur de trafic entrant natif OCI en tant que programme autonome

Pour créer un équilibreur de charge et acheminer le trafic entrant, le contrôleur de trafic entrant natif OCI, qu'il soit installé en tant que programme autonome ou en tant que module complémentaire de grappe, effectue des actions sur d'autres ressources de service Oracle Cloud Infrastructure (y compris le service d'équilibreur de charge et le service de certificats). Pour effectuer ces actions sur les ressources de service OCI, le pod du contrôleur de trafic entrant natif OCI utilise les données d'identification d'un acteur autorisé (ou principal). Vous pouvez actuellement configurer les types de principal suivants pour permettre au contrôleur de trafic entrant natif OCI d'effectuer des actions sur les ressources de service OCI :

• Principal d'instance : Le contrôleur de trafic entrant natif OCI utilise l'identité de l'instance sur laquelle il s'exécute. Voir Utilisation des principaux d'instance pour permettre l'accès aux services et ressources OCI.
• Principal d'utilisateur : Le contrôleur de trafic entrant natif OCI utilise l'identité d'un utilisateur OCI. Voir Utilisation des principaux d'utilisateur pour permettre l'accès aux services et ressources OCI.
• Principal d'identité de charge de travail : Le contrôleur de trafic entrant natif OCI utilise l'identité d'une ressource de charge de travail exécutée sur une grappe Kubernetes. Voir Utilisation des principaux d'identité de charge de travail pour permettre l'accès aux services et ressources OCI.

Note :

• L'utilisation de principaux d'instance pour permettre au contrôleur de trafic entrant natif OCI d'accéder aux services et ressources OCI n'est pas prise en charge dans les grappes avec des noeuds virtuels.
• L'utilisation de principaux d'identité de charge de travail pour permettre au contrôleur de trafic entrant natif OCI d'accéder aux services et ressources OCI est prise en charge avec des grappes améliorées, mais pas avec des grappes de base.

Le contrôleur de trafic entrant natif OCI nécessite des autorisations pour accéder aux ressources créées par d'autres services Oracle Cloud Infrastructure (tels que le service d'équilibreur de charge et le service de certificats). Les autorisations que vous accordez sont les mêmes, que vous installiez le contrôleur de trafic entrant natif OCI en tant que programme autonome ou en tant que module complémentaire de grappe. En outre, les autorisations sont les mêmes, que vous ayez configuré un principal d'instance, un principal d'utilisateur ou un principal d'identité de charge de travail pour le contrôleur de trafic entrant natif OCI. Toutefois, la façon dont vous accordez ces autorisations dépend du type de principal que vous avez configuré :

• Lorsque vous utilisez des principaux d'instance, le contrôleur de trafic entrant natif OCI hérite des autorisations accordées à l'instance sur laquelle il s'exécute au moyen d'un groupe dynamique auquel l'instance appartient. Pour plus d'informations sur la création du groupe dynamique pour les principaux d'instance, voir Utilisation des principaux d'instance pour permettre l'accès aux services et ressources OCI.
• Lorsque vous utilisez des principaux d'utilisateur, le contrôleur de trafic entrant natif OCI hérite des autorisations accordées à un utilisateur au moyen d'un groupe auquel l'utilisateur appartient. Pour plus d'informations sur la création de l'utilisateur et du groupe pour les principaux d'utilisateur, voir Utilisation des principaux d'utilisateur pour permettre l'accès aux services et ressources OCI.
• Lorsque vous utilisez des principaux d'identité de charge de travail, le contrôleur de trafic entrant natif OCI hérite des autorisations accordées à une charge de travail exécutée sur une grappe spécifiée, dans le compte de service Kubernetes et l'espace de noms créés pour le contrôleur de trafic entrant natif OCI lors de l'installation. Pour plus d'informations, voir Utilisation des principaux d'identité de charge de travail pour permettre l'accès aux services et ressources OCI.

Pour configurer des autorisations pour le contrôleur de trafic entrant natif OCI, créez une politique pour le groupe (dans le cas des principaux d'utilisateur), pour le groupe dynamique (dans le cas des principaux d'instance) ou pour la charge de travail (dans le cas des principaux d'identité de charge de travail), avec des énoncés de politique pour accéder aux services et aux ressources OCI :

1. Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous identité, sélectionnez Politiques.
2. Suivez les instructions sous Pour créer une politique et donnez un nom à la politique (par exemple, acme-oke-native-ingress-controller-policy).

3. Si vous utilisez des principaux d'instance ou d'utilisateur, entrez des énoncés de politique pour autoriser l'accès aux services et ressources OCI utilisés par le contrôleur de trafic entrant natif OCI, dans le format suivant :

   Allow <group|dynamic-group> <subject-name> to <verb> <resource> in <location>   
   

   où :

   • <group|dynamic-group> est group (dans le cas des principaux d'utilisateur) ou dynamic-group (dans le cas des principaux d'instance)
   • <subject-name> est le nom du groupe (dans le cas des principaux d'utilisateur) ou le nom du groupe dynamique (dans le cas des principaux d'instance). Par exemple, acme-oke-nat-ing-cont-dyn-grp. Notez que si un groupe ou un groupe dynamique ne se trouve pas dans le domaine d'identité par défaut, ajoutez le préfixe <group|dynamic-group> '<identity-domain-name>'/'<group-name|dynamic-group-name>' au nom du groupe ou du groupe dynamique. Vous pouvez également spécifier un groupe ou un groupe dynamique à l'aide de son OCID, dans le format group id <group-ocid> ou dynamic-group id <dynamic-group-ocid>.
   • <verb> <resource> est l'un des suivants (toutes ces opérations sont requises dans des énoncés de politique distincts) :
     • manage load-balancers
     • use virtual-network-family
     • manage cabundles
     • manage cabundle-associations
     • manage leaf-certificates
     • read leaf-certificate-bundles
     • manage leaf-certificate-versions
     • manage certificate-associations
     • read certificate-authorities
     • manage certificate-authority-associations
     • read certificate-authority-bundles
     • read public-ips
     • manage floating-ips
     • manage waf-family
     • read cluster-family
     • use tag-namespaces (obligatoire uniquement si vous voulez que le contrôleur de trafic entrant natif OCI applique des marqueurs définis aux équilibreurs de charge, voir Application de marqueurs définis à l'équilibreur de charge)
   • <location> est l'un des suivants :
     • tenancy, si vous voulez que le contrôleur de trafic entrant natif OCI ait accès aux ressources de l'ensemble de la location.
     • compartment <compartment-name> si vous voulez que le contrôleur de trafic entrant natif OCI ait uniquement accès aux ressources du compartiment portant le nom compartment <compartment-name>.

   Par exemple :

   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment

   La syntaxe de la liste complète des énoncés de politique est la suivante :

   Allow <group|dynamic-group> <subject-name> to manage load-balancers in <location>   
   Allow <group|dynamic-group> <subject-name> to use virtual-network-family in <location>
   Allow <group|dynamic-group> <subject-name> to manage cabundles in <location>
   Allow <group|dynamic-group> <subject-name> to manage cabundle-associations in <location>
   Allow <group|dynamic-group> <subject-name> to manage leaf-certificates in <location>
   Allow <group|dynamic-group> <subject-name> to read leaf-certificate-bundles in <location>
   Allow <group|dynamic-group> <subject-name> to manage leaf-certificate-versions in <location>
   Allow <group|dynamic-group> <subject-name> to manage certificate-associations in <location>
   Allow <group|dynamic-group> <subject-name> to read certificate-authorities in <location>
   Allow <group|dynamic-group> <subject-name> to manage certificate-authority-associations in <location>
   Allow <group|dynamic-group> <subject-name> to read certificate-authority-bundles in <location>
   Allow <group|dynamic-group> <subject-name> to read public-ips in <location>
   Allow <group|dynamic-group> <subject-name> to manage floating-ips in <location>
   Allow <group|dynamic-group> <subject-name> to manage waf-family in <location>
   Allow <group|dynamic-group> <subject-name> to read cluster-family in <location>
   Allow <group|dynamic-group> <subject-name> to use tag-namespaces in <location>

   Exemple de liste complète d'énoncés de politique :

   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment   
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use virtual-network-family in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundles in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundle-associations in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage leaf-certificates in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read leaf-certificate-bundles in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage leaf-certificate-versions in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-associations in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authorities in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-authority-associations in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authority-bundles in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read public-ips in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage floating-ips in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage waf-family in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read cluster-family in compartment acme-oke-cluster-compartment
   Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use tag-namespaces in compartment acme-oke-cluster-compartment

4. Si vous utilisez des principaux d'identité de charge de travail, entrez des énoncés de politique pour autoriser l'accès aux services et ressources OCI utilisés par le contrôleur de trafic entrant natif OCI, dans le format suivant :

   Allow any-user to <verb> <resource> in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

   où :

   • <verb> <resource> est l'un des suivants (toutes ces opérations sont requises dans des énoncés de politique distincts) :
     • manage load-balancers
     • use virtual-network-family
     • manage cabundles
     • manage cabundle-associations
     • manage leaf-certificates
     • read leaf-certificate-bundles
     • manage leaf-certificate-versions
     • manage certificate-associations
     • read certificate-authorities
     • manage certificate-authority-associations
     • read certificate-authority-bundles
     • read public-ips
     • manage floating-ips
     • manage waf-family
     • read cluster-family
     • use tag-namespaces (obligatoire uniquement si vous voulez que le contrôleur de trafic entrant natif OCI applique des marqueurs définis aux équilibreurs de charge, voir Application de marqueurs définis à l'équilibreur de charge)
   • <location> est l'un des suivants :
     • tenancy, si vous voulez que le contrôleur de trafic entrant natif OCI ait accès aux ressources de l'ensemble de la location.
     • compartment <compartment-name> si vous voulez que le contrôleur de trafic entrant natif OCI ait uniquement accès aux ressources du compartiment portant le nom compartment <compartment-name>.
   • request.principal.namespace = 'native-ingress-controller-system' est le nom de l'espace de noms créé pour le contrôleur de trafic entrant natif OCI lors de l'installation.
   • request.principal.service_account = 'oci-native-ingress-controller' est le nom du compte de service créé pour le contrôleur de trafic entrant natif OCI lors de l'installation.
   • <cluster-ocid> est l'OCID de la grappe que vous avez obtenu précédemment.

   Par exemple :

   Allow any-user to manage load-balancers in tenancy where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa______ska'}

   La syntaxe pour la liste complète des énoncés de politique est la suivante :

   Allow any-user to manage load-balancers in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to use virtual-network-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to manage cabundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to manage cabundle-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to manage leaf-certificates in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to read leaf-certificate-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to manage leaf-certificate-versions in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to manage certificate-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to read certificate-authorities in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to manage certificate-authority-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to read certificate-authority-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to read public-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to manage floating-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to manage waf-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to read cluster-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
   Allow any-user to use tag-namespaces in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

Le contrôleur de trafic entrant natif OCI, qu'il soit installé en tant que programme autonome ou en tant que module complémentaire de grappe, utilise des webhooks pour injecter des portes de disponibilité des pods dans les spécifications de pod. Pour assurer la sécurité, le serveur webhook doit fonctionner en mode HTTPS, ce qui nécessite une paire de certificats et de clés. Le contrôleur de trafic entrant natif OCI utilise le gestionnaire de certificats (également connu sous le nom de gestionnaire de certificats) pour générer et gérer les certificats et les clés pour le serveur de webhook. Vous devez donc installer le gestionnaire de certificats sur la grappe pour utiliser les portes de disponibilité des pods.

Que vous installiez le contrôleur de trafic entrant natif OCI en tant que programme autonome ou en tant que module complémentaire de grappe, vous pouvez installer et exécuter cert-manager de deux façons :

• Vous pouvez installer et exécuter cert-manager en tant que produit open source, en entrant :

  kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml

• Vous pouvez installer et exécuter cert-manager en tant que module complémentaire de grappe. Pour plus d'informations sur l'installation de cert-manager en tant que module complémentaire de grappe, voir Installation d'un module complémentaire de grappe.

Pour plus d'informations sur cert-manager, consultez la documentation sur cert-manager.io.