Configurer des instances pour les services d'appel

Une instance de calcul en périphérie de réseau Rover peut être configurée pour permettre aux applications s'exécutant sur l'instance d'appeler des services et de gérer des ressources de la même manière que les utilisateurs en périphérie de réseau Rover appellent des services pour gérer des ressources.

Un principal d'instance est une instance de calcul autorisée à effectuer des actions sur les ressources de service. Les applications s'exécutant sur un principal d'instance peuvent appeler des services et gérer des ressources de la même façon que les utilisateurs d'Oracle en périphérie de réseau Rover appellent des services pour gérer des ressources. L'instance est un acteur principal, tout comme un utilisateur est un acteur principal. Lorsque vous utilisez des principaux d'instance, vous n'avez pas besoin de configurer des données d'identification d'utilisateur ou un fichier de configuration sur l'instance pour exécuter des applications qui doivent gérer les ressources de service.

Pour accorder des autorisations à un principal d'instance, incluez l'instance en tant que membre d'un groupe dynamique. Un groupe dynamique fournit des autorisations aux instances tout comme un groupe d'utilisateurs fournit des autorisations aux utilisateurs.

La fonction de service IAM qui permet aux instances d'être des acteurs (ou 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 qui accorde des autorisations pour accéder aux ressources requises. Voir Création et gestion de groupes dynamiques.

L'instance doit être créée ou déplacée vers un compartiment nommé dans une règle de correspondance du groupe dynamique, ou un marqueur de ressource affecté à l'instance doit être nommé dans une règle de correspondance. Voir Écriture de règles de correspondance.

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

Cette rubrique 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 mises à 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

Par défaut, les points d'extrémité en périphérie de réseau Rover (tels que iaas et identity) offrent un certificat signé par une autorité de certification spécifique à cet appareil. Par défaut, les systèmes d'exploitation ne font pas confiance aux certificats signés par une autorité de certification spécifique à cette périphérie de réseau Rover. Si le système d'exploitation ne fait pas confiance aux certificats offerts, les tentatives d'utilisation de la trousse SDK ou de l'interface de ligne de commande OCI échoueront 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.

Note

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)

Si vous disposez d'un certificat signé par une autorité de certification à laquelle votre système d'exploitation fait confiance, configurez la périphérie de réseau Rover pour offrir ce certificat.

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

Pour plus d'informations sur la façon de fournir votre propre certificat, voir "Accès aux interfaces externes avec votre chaîne de confiance AC".

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

Cette méthode copie l'ensemble AC propre au boîtier 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 du boîtier.
```
curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_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 un grand nombre d'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 en périphérie de réseau Rover dans le monde

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.

Note

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 du boîtier.

curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_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 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 pendant l'initialisation, ce qui évite d'effectuer ces étapes manuellement sur un grand nombre d'instances.

Configuration de la trousse SDK Python et de l'interface de ligne de commande pour les principaux d'instance

Cette rubrique décrit comment activer l'autorisation du principal d'instance pour la trousse SDK Python, l'interface de ligne de commande ou Terraform.

Activation de l'autorisation du principal d'instance pour la trousse SDK Python

Dans votre trousse SDK pour Python, créez un objet oci.auth.signers.InstancePrincipalsSecurityTokenSigner comme illustré dans l'exemple suivant :

# 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

Définissez l'option d'autorisation (--auth) pour une commande comme illustré dans l'exemple suivant :

oci os ns get --auth instance_principal

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

OCI_CLI_AUTH=instance_principal

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

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

Réglez 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.

Documentation sur Oracle Cloud Infrastructure