Configuration d'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 de principaux) afin d'effectuer des actions sur des ressources du 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.

Configuration de 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 du 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 persistantes les modifications de configuration

Procédez comme suit pour que ces modifications de configuration de pare-feu persistent après la réinitialisation de l'instance.

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

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 lors de l'initialisation.

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 moment de l'initialisation.
```
systemctl daemon-reload
systemctl enable restore-iptables
```

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

Par défaut, sur Compute Cloud@Customer, 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 à ce 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 le kit SDK ou l'interface de ligne de commande OCI sur l'instance.

Important

Tout utilisateur ayant accès à l'instance via une connexion SSH hérite automatiquement du privilège octroyé à celle-ci.

Option 1 : utilisation de votre 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 certification 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 CA 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 garantir la sécurité, vérifiez le contenu du groupe extrait (external_ca.crt).

Extrayez le certificat de l'adresse iaas de 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 lors de l'initialisation, ce qui permet d'économiser les efforts de récupération 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 du 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 : approbation globale du package d'autorité de certification Compute Cloud@Customer

Cette méthode est identique à 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 du kit SDK, cette méthode ajoute le package d'autorité de certification à la chaîne de sécurisation.

Important

Lorsque le package d'autorité de certification est ajouté à la chaîne de confiance, chaque application sur cette instance de calcul fera 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 de l'adresse iaas de 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 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 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 s'exécute par cloud-init à l'intérieur de l'instance pendant l'initialisation, ce qui permet d'économiser le temps nécessaire pour effectuer ces étapes manuellement sur de nombreuses instances.