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 Compute Cloud@Customer appellent des services pour gérer des ressources.

La fonctionnalité du service IAM permettant aux instances d'être des acteurs autorisés (ou des principaux) pour 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 adresses de service. Reportez-vous à 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 droits d'accès aux ressources requises. Reportez-vous à Gestion des groupes dynamiques.

L'instance doit être créée ou déplacée vers un compartiment nommé dans une règle de mise en correspondance du groupe dynamique, ou une balise de ressource nommée dans une règle de mise en correspondance doit être affectée à l'instance. Reportez-vous à Ecriture de règles de mise en correspondance pour définir des groupes dynamiques.

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

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

Modification de la configuration du pare-feu

En tant qu'utilisateur privilégié, modifiez la configuration de pare-feu d'instance pour permettre à l'instance d'accéder aux adresses de service telles 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 toutes les adresses. La deuxième entrée est requise pour contacter l'adresse Object Storage.

Rendre les modifications de configuration persistantes

Utilisez la procédure suivante pour que ces modifications de configuration de pare-feu persistent après les réinitialisations d'instance.

Enregistrez la configuration des tables IP mise à jour.
```
iptables-save > /etc/sysconfig/iptables.rules
```
Créez un script pour restaurer automatiquement la configuration actuelle (modifiée) du pare-feu à la réinitialisation.

Dans cet exemple, le script est nommé /sbin/restore-iptables.sh. Voici le contenu du fichier /sbin/restore-iptables.sh :
```
#!/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 lors de l'initialisation.

Dans cet exemple, le service est nommé /etc/systemd/system/restore-iptables.service. Voici le contenu du fichier /etc/systemd/system/restore-iptables.service :
```
[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 moment de l'initialisation.
```
systemctl daemon-reload
systemctl enable restore-iptables
```

Configuration de certificats d'instance pour autoriser l'appel de services

Sur Compute Cloud@Customer, par défaut, les adresses (telles 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 ne fait pas confiance aux certificats proposés, les tentatives d'utilisation du kit SDK ou de l'interface de ligne de commande OCI échouent avec une erreur CERTIFICATE_VERIFY_FAILED.

Implémentez l'une des solutions décrites dans cette rubrique pour utiliser l'interface de ligne de commande ou le kit SDK OCI sur l'instance.

Important

Tout utilisateur disposant d'une connexion SSH à l'instance hérite automatiquement des privilèges octroyés à celle-ci.

Option 1 : Utilisation de votre propre certificat (BYOC)

Sur Compute Cloud@Customer, vous pouvez fournir vos propres certificats d'autorité de certification, ce qui vous permet d'utiliser votre chaîne de confiance d'autorité de certification. Pour utiliser vos propres certificats, ouvrez une demande d'assistance et demandez à utiliser vos propres certificats. Reportez-vous à Création d'une demande d'assistance. Pour accéder au support technique, connectez-vous à la console Oracle Cloud comme décrit dans Connexion à la console OCI.

Sur un O/S Linux, la commande suivante répertorie les autorités de certification sécurisées par défaut :

trust list --filter=ca-anchors

Option 2 : indiquer dans le code SDK le package d'autorité de certification à utiliser

Cette méthode copie le package d'autorité de certification 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 du groupe extrait (external_ca.crt).

Extrayez le certificat à partir de l'adresse 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 se trouver dans un script transmis à l'instance lors 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 à l'intérieur de l'instance pendant 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 du package d'autorité de certification enregistré dans le fichier external_ca.crt.

Indiquez le package d'autorité de certification dans le code de kit 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 : Sécuriser globalement le package d'autorité de certification 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 le package d'autorité de certification dans le code SDK, cette méthode ajoute le package d'autorité de certification à la chaîne d'approbation.

Important

Lorsque le package d'autorité de certification est ajouté à la chaîne d'approbation, toutes les applications de cette instance de calcul font confiance aux certificats signés avec l'autorité de certification indiquée dans ce package. Déterminez s'il s'agit d'un risque de sécurité acceptable.

Extrayez le certificat à partir de l'adresse 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 du package d'autorité de certification enregistré dans le fichier external_ca.crt.
Mettez à jour la chaîne de confiance de l'autorité de certification globale.
```
cp external_ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract
```

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