Configurer des instances pour appeler des services

Une instance de calcul Compute Cloud@Customer peut être configurée pour permettre aux applications exécutées sur l'instance d'appeler des services et de gérer des ressources de la même manière que les utilisateurs de Compute Cloud@Customer appellent des services pour gérer les ressources.

La fonction de service IAM qui permet aux instances d'être des acteurs (ou des principaux) autorisés à effectuer des actions sur les ressources de service est appelée principal d'instance.

Pour configurer et utiliser une instance en tant que principal, procédez comme suit :

Configurez le pare-feu d'instance pour permettre à l'instance d'accéder aux points d'extrémité du service. Voir Configuration de pare-feu d'instance pour autoriser les services d'appel.
Assurez-vous que l'instance est incluse dans un groupe dynamique (configuré dans votre location) qui accorde des autorisations pour accéder aux ressources requises. Voir Gestion des groupes dynamiques.

L'instance doit être créée ou déplacée vers un compartiment qui est nommé dans une règle de correspondance du groupe dynamique, ou l'instance doit avoir un marqueur de ressource affecté qui est nommé dans une règle de correspondance. Voir écriture des règles de correspondance pour définir des groupes dynamiques.

Configurer des pare-feu d'instance pour autoriser les services d'appel

Cette section décrit comment modifier la configuration du pare-feu d'instance et comment créer un service systemd pour restaurer les modifications si le système redémarre.

Modifier la configuration du pare-feu

En tant qu'utilisateur privilégié, modifiez la configuration du pare-feu d'instance pour permettre à l'instance d'accéder aux points d'extrémité du service tels que iaas et identity.
Utilisez la commande iptables pour ajouter les règles BareMetalInstanceServices suivantes au pare-feu d'instance :
```
iptables -I BareMetalInstanceServices 14 -p tcp -d 169.254.169.254 --dport 443 -j ACCEPT
iptables -I BareMetalInstanceServices 14 -p tcp -d 169.254.240.254 --dport 443 -j ACCEPT
```
La première entrée est requise pour tous les points d'extrémité. La deuxième entrée est requise pour communiquer avec le point d'extrémité du service de stockage d'objets.

Rendre les modifications de configuration persistantes

Utilisez la procédure suivante pour rendre ces modifications de configuration de pare-feu persistantes lors des redémarrages de l'instance.

Enregistrez la configuration des tables IP mise à jour.
```
iptables-save > /etc/sysconfig/iptables.rules
```
Créez un script pour restaurer automatiquement la configuration de pare-feu courante (modifiée) au redémarrage.

Dans cet exemple, le script est nommé /sbin/restore-iptables.sh. Le contenu du fichier /sbin/restore-iptables.sh est le suivant :
```
#!/bin/sh
/sbin/iptables-restore < /etc/sysconfig/iptables.rules
```
Définissez le bit exécutable sur le script.
```
chmod +x /sbin/restore-iptables.sh
```
Créez un service systemd oneshot pour exécuter le script /sbin/restore-iptables.sh au démarrage.

Dans cet exemple, le service est nommé /etc/systemd/system/restore-iptables.service. Le contenu du fichier /etc/systemd/system/restore-iptables.service est le suivant :
```
[Unit]
Description=Restore IP Tables
After=cloud-final.service

[Service]
ExecStart=/sbin/restore-iptables.sh
User=root
Group=root
Type=oneshot

[Install]
WantedBy=multi-user.target
```
Rechargez la configuration du gestionnaire systemd et activez l'exécution du service au démarrage.
```
systemctl daemon-reload
systemctl enable restore-iptables
```

Configuration des certificats d'instance pour autoriser les services d'appel

Sur Compute Cloud@Customer, par défaut, les points d'extrémité (tels que iaas et identity) offrent un certificat signé par une autorité de certification propre à Compute Cloud@Customer. Par défaut, les systèmes d'exploitation ne font pas confiance aux certificats signés par une autorité de certification propre à Compute Cloud@Customer. Si le système d'exploitation n'approuve pas les certificats offerts, les tentatives d'utilisation de la trousse SDK ou de l'interface de ligne de commande OCI échouent avec une erreur CERTIFICATE_VERIFY_FAILED.

Mettez en oeuvre l'une des solutions décrites dans cette rubrique pour utiliser avec succès la trousse SDK ou l'interface de ligne de commande OCI sur l'instance.

Important

Tout utilisateur pouvant accéder à l'instance par SSH hérite automatiquement des privilèges accordés à l'instance.

Option 1 : Utiliser son propre certificat (BYOC)

Sur Compute Cloud@Customer, vous pouvez fournir vos propres certificats d'autorité de certification qui vous permettent d'utiliser votre chaîne de confiance d'autorité de certification. Pour utiliser vos propres certificats, ouvrez une demande de soutien et demandez d'utiliser vos propres certificats. Voir Création d'une demande de soutien. Pour accéder au soutien technique, connectez-vous à la console Oracle Cloud, comme décrit sous Se connecter à la console OCI.

Sur un système d'exploitation Linux, la commande suivante liste les autorités de certification qui sont approuvées par défaut :

trust list --filter=ca-anchors

Option 2 : Spécifier dans le code de trousse SDK l'ensemble AC à utiliser

Cette méthode copie l'ensemble AC propre à Compute Cloud@Customer vers l'instance, mais ne vérifie pas le certificat du serveur (--insecure). Pour assurer la sécurité, vérifiez le contenu de l'ensemble extrait (external_ca.crt).

Extrayez le certificat du point d'extrémité iaas de l'infrastructure Compute Cloud@Customer.
```
curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.ccc_name.domain_name/cachain
```
Cette commande peut figurer dans un script qui est transmis à l'instance au moment du lancement à l'aide de l'option --user-data-file ou de l'option --metadata avec un champ user_data. Le script sera exécuté par cloud-init dans l'instance lors de l'initialisation, ce qui permet d'économiser l'effort d'extraction manuelle de ce fichier de certificat sur de nombreuses instances.
Vérifiez le contenu de l'ensemble AC enregistré dans le fichier external_ca.crt.

Spécifiez l'ensemble AC dans le code de la trousse SDK Python.

signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner(
    federation_client_cert_bundle_verify="/home/opc/external_ca.crt"
)
identity_client = oci.identity.IdentityClient(config={}, signer=signer)
identity_client.base_client.session.verify = "/home/opc/external_ca.crt"

Option 3 : Faire confiance à l'ensemble AC d'Oracle Compute Cloud@Customer

Cette méthode est la même que la méthode précédente avec la différence suivante : Au lieu de spécifier l'ensemble AC dans le code SDK, cette méthode ajoute l'ensemble AC à la chaîne d'approbation.

Important

Lorsque l'ensemble AC est ajouté à la chaîne d'approbation, chaque application de cette instance de calcul approuve les certificats signés avec l'autorité de certification spécifiée dans cet ensemble. Déterminez s'il s'agit d'un risque de sécurité acceptable.

Extrayez le certificat du point d'extrémité iaas de l'infrastructure Compute Cloud@Customer.

curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.ccc_name.domain_name/cachain

Vérifiez le contenu de l'ensemble AC enregistré dans le fichier external_ca.crt.
Mettez à jour la chaîne d'approbation globale de l'autorité de certification.
```
cp external_ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
```

Les étapes 1 et 3 de cette méthode peuvent se trouver dans un script qui est transmis à l'instance au moment du lancement à l'aide de l'option --user-data-file ou de l'option --metadata avec un champ user_data. Le script s'exécute par cloud-init dans l'instance lors de l'initialisation, ce qui évite d'effectuer ces étapes manuellement sur de nombreuses instances.