Documentation sur Oracle Cloud Infrastructure

Appel de services depuis une instance

Cette rubrique décrit comment autoriser des instances à appeler des services dans Oracle Cloud Infrastructure.

Présentation

Cette procédure décrit comment autoriser une instance à effectuer des appels d'API dans les services Oracle Cloud Infrastructure. Une fois les ressources et politiques requises configurées, une application s'exécutant sur une instance peut appeler les services publics Oracle Cloud Infrastructure, ce qui supprime la nécessité de configurer les données d'identification d'utilisateur ou de définir un fichier de configuration.

Concepts

GROUPE DYNAMIQUE
Les groupes dynamiques vous permettent de regrouper des instances Oracle Cloud Infrastructure en tant qu'acteurs principaux, similaires aux groupes d'utilisateurs. Vous pouvez ensuite créer des politiques pour autoriser les instances de ces groupes à effectuer des appels d'API pour les services Oracle Cloud Infrastructure. L'appartenance au groupe est déterminée par un jeu de critères que vous définissez, appelés règles de correspondance.
RÈGLE DE CORRESPONDANCE
Lorsque vous configurez un groupe dynamique, vous définissez également les règles d'appartenance au groupe. Les ressources correspondant aux critères de la règle sont membres du groupe dynamique. Les règles de correspondance comportent une syntaxe spécifique que vous devez respecter. Voir Écriture des règles de correspondance pour définir des groupes dynamiques.
PRINCIPAUX D'INSTANCE
Fonction du service GIA qui permet aux instances d'être des acteurs autorisés (ou principaux) à effectuer des actions sur les ressources du service. Chaque instance de calcul possède sa propre identité et s'authentifie à l'aide des certificats qui y sont ajoutés. Comme ces certificats sont créés automatiquement, affectés à des instances et modifiés, vous n'avez pas besoin de transmettre des données d'identification à vos hôtes ni de les modifier.

Considérations relatives à la sécurité

Tout utilisateur ayant accès à l'instance (accès SSH à l'instance) hérite automatiquement des privilèges accordés à l'instance. Avant d'accorder des autorisations à une instance à l'aide de cette procédure, assurez-vous de savoir qui peut y accéder et que ces utilisateurs disposent des autorisations que vous octroyez à l'instance.

Tous les principaux d'instance de calcul bénéficient de l'autorisation compartment_inspect. Vous ne pouvez pas révoquer cette autorisation. Cette autorisation permet à l'instance ListCompartments de la location d'extraire les informations suivantes :

Aperçu du processus

Les étapes suivantes récapitulent le flux de processus pour configurer et utiliser des instances en tant que principaux d'instance. Les sections suivantes fournissent des informations plus détaillées.

  1. Créer un groupe dynamique. Dans la définition du groupe dynamique, vous indiquez les règles correspondantes pour spécifier les instances que vous voulez autoriser à effectuer des appels d'API aux services.

  2. Créer une politique qui accorde des autorisations au groupe dynamique pour accéder aux services de votre location (ou compartiment).

  3. Un développeur dans votre organisation configure l'application créée à l'aide de la trousse SDK Oracle Cloud Infrastructure pour l'authentification à l'aide du fournisseur de principaux d'instance. Le développeur déploie l'application et la trousse SDK pour toutes les instances qui appartiennent au groupe dynamique.

  4. La trousse SDK déployée effectue des appels aux API Oracle Cloud Infrastructure telles que la politique les y autorise (sans avoir à configurer des données d'identification d'API).

  5. Pour chaque appel d'API effectué par une instance, le service de vérification enregistre l'événement, en enregistrant l'OCID de l'instance en tant que valeur principalId dans le journal des événements. Pour plus d'informations, voir Contenu d'un événement du journal de vérification.

Étapes pour permettre à des instances d'appeler des services

Exécutez les tâches suivantes pour permettre à des instances d'appeler des services :

Créer un groupe dynamique et des règles de correspondance

Écrire des politiques pour des groupes dynamiques

Configurer la trousse SDK, l'interface de ligne de commande ou Terraform

Écriture des politiques pour les groupes dynamiques

Après avoir créé un groupe dynamique, vous devez créer des politiques pour permettre aux groupes dynamiques d'accéder aux services Oracle Cloud Infrastructure.

La politique relative aux groupes dynamiques respecte la syntaxe décrite dans Fonctionnement des politiques. Consultez cette rubrique pour comprendre les fonctions de base des politiques.

La syntaxe pour permettre à un groupe dynamique d'accéder aux ressources d'un compartiment est la suivante :

Allow dynamic-group <dynamic_group_name> to <verb> <resource-type> in compartment <compartment_name>

La syntaxe pour permettre à un groupe dynamique d'accéder à une location est la suivante :

Allow dynamic-group <dynamic_group_name> to <verb> <resource-type> in tenancy

Voici quelques exemples de politique :

Pour permettre à un groupe dynamique (FrontEnd) d'utiliser un équilibreur de charge dans un compartiment spécifique (ProjectA) :

Allow dynamic-group FrontEnd to use load-balancers in compartment ProjectA

Pour permettre à un groupe dynamique de lancer des instances dans un compartiment spécifique :

Allow dynamic-group FrontEnd to manage instance-family in compartment ProjectA
Allow dynamic-group FrontEnd to use volume-family in compartment ProjectA
Allow dynamic-group FrontEnd to use virtual-network-family in compartment ProjectA

Pour d'autres exemples de politique, voir Politiques courantes.

Configuration de la trousse SDK, de l'interface de ligne de commande ou de Terraform

Pour plus d'informations sur les trousses SDK, voir Trousses SDK et interface de ligne de commande.

Pour la trousse SDK pour Java :

Dans la trousse SDK pour Java, créez un objet InstancePrincipalsAuthenticationDetailsProvider. Par exemple :

public static void main(String[] args) throws Exception {

   InstancePrincipalsAuthenticationDetailsProvider provider =

      InstancePrincipalsAuthenticationDetailsProvider.builder().build();

   IdentityClient identityClient = new IdentityClient(provider);

...

Pour la trousse SDK Python :

Dans la trousse SDK Python, créez un objet oci.auth.signers.InstancePrincipalsSecurityTokenSigner. Par exemple :

# By default this will hit the auth service in the region returned by http://169.254.169.254/opc/v1/instance/region on the instance.
			
signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner()
identity_client = oci.identity.IdentityClient(config={}, signer=signer)

...

Pour actualiser le jeton sans attendre, utilisez la commande suivante :

signer.refresh_security_token()

Activation de l'autorisation du principal d'instance pour l'interface de ligne de commande

Pour activer l'autorisation du principal d'instance à partir de l'interface de ligne de commande, vous pouvez définir l'option d'autorisation (--auth) pour une commande. Par exemple :

oci os ns get --auth instance_principal

Vous pouvez également définir la variable d'environnement suivante :

OCI_CLI_AUTH=instance_principal

Notez que si les deux sont définies, la valeur définie pour --auth a priorité sur la variable d'environnement.

Pour plus d'informations sur l'utilisation de l'interface de ligne de commande, voir Utilisation de l'interface de ligne de commande.

Activation de l'autorisation du principal d'instance pour Terraform

Pour activer l'autorisation du principal d'instance dans Terraform, vous pouvez régler l'attribut auth à "InstancePrincipal" dans la définition du fournisseur, comme illustré dans l'exemple suivant :

variable "region" {}

provider "oci" {
   auth = "InstancePrincipal"  
   region = "${var.region}"

}

Lorsque vous utilisez l'autorisation du principal d'instance, vous n'avez pas besoin d'inclure les attributs tenancy_ocid, user_ocid, fingerprint et private_key_path.

FAQ

Comment interroger le service de métadonnées de l'instance pour interroger le certificat sur l'instance?

Utilisez cette commande curl : curl http://169.254.169.254/opc/v1/identity/cert.pem

Quelle est la fréquence de modification du certificat sur chaque instance?

Le certificat est modifié plusieurs fois par jour.

Que se passe-t-il si je reçois une erreur 401-Not Authenticated?
Si vous recevez une erreur 401-Not Authenticated (Non authentifié), vérifiez les problèmes suivants :
  • Essayez d'exécuter à nouveau la commande. Parfois, la rotation du certificat et la demande se produisent en même temps.
  • Le certificat a peut-être expiré. Vérifiez que le certificat est valide.
Puis-je modifier la fréquence de modification du certificat?

Non. Vous ne pouvez pas modifier la fréquence à laquelle le certificat est modifié. Toutefois, vous pouvez modifier la politique sur le groupe dynamique. Si vous pensez qu'une instance a été compromise, vous pouvez modifier la politique sur le groupe dynamique pour révoquer ses autorisations pour tous les membres du groupe ou supprimer l'instance du groupe dynamique. Voir Puis-je supprimer une instance d'un groupe dynamique?

Que se passe-t-il si le certificat est modifié au milieu d'une opération de longue durée?

L'expiration du jeton est indépendante de la période d'expiration du certificat. Par ailleurs, elle dépend de l'application avec laquelle vous interagissez. Par exemple, si le service de stockage d'objets ne comporte pas d'opération PUT en plusieurs parties, peu importe la durée de l'exécution de l'opération.

Les certificats sont-ils accessibles pour tous les utilisateurs sur une instance?

Oui. Assurez-vous que seuls les utilisateurs autorisés à accéder au groupe dynamique ont accès à l'instance.

Puis-je retirer une instance d'un groupe dynamique?

Oui. Vous pouvez la retirer en modifiant la règle de correspondance pour l'exclure. Voir ci-dessous pour un exemple.

Puis-je exclure des instances spécifiques d'un compartiment du groupe dynamique?

Oui. Par exemple, supposons que vous vouliez exclure deux instances spécifiques d'un compartiment du groupe dynamique. Écrivez une règle de correspondance comme celle-ci :

All {instance.compartment.id = '<compartment_ocid>',
 instance.id != '<instance1_to_exclude_ocid>', instance.id != '<instance2_to_exclude_ocid>'}

La règle ci-dessus inclut toutes les instances du compartiment, sauf celles dont les OCID sont spécifiés.