Instanzen für den Aufruf von Services konfigurieren

Eine Compute Cloud@Customer-Compute-Instanz kann so konfiguriert werden, dass Anwendungen, die auf der Instanz ausgeführt werden, Services aufrufen und Ressourcen verwalten können, ähnlich wie Compute Cloud@Customer-Benutzer Services zum Verwalten von Ressourcen aufrufen.

Das IAM-Servicefeature, mit dem Instanzen als autorisierte Akteure (oder Principals) Aktionen für Serviceressource ausführen können, wird als Instanz-Principal bezeichnet.

Führen Sie die folgenden Schritte aus, um eine Instanz als Principal einzurichten und zu verwenden:

Konfigurieren Sie die Instanzfirewall, damit die Instanz auf Serviceendpunkte zugreifen kann. Siehe Instanz-Firewalls konfigurieren, um Aufrufe von Services zuzulassen.
Stellen Sie sicher, dass die Instanz in einer dynamischen Gruppe (in Ihrem Mandanten konfiguriert) enthalten ist, die Berechtigungen für den Zugriff auf die erforderlichen Ressourcen erteilt. Siehe Dynamische Gruppen verwalten.

Die Instanz muss in einem Compartment erstellt oder in ein Compartment verschoben werden, das in einer Übereinstimmungsregel der dynamischen Gruppe benannt ist, oder der Instanz muss ein Ressourcentag zugewiesen sein, das in einer Übereinstimmungsregel benannt ist. Informationen hierzu finden Sie unter Übereinstimmungsregeln zum Definieren dynamischer Gruppen schreiben.

Instanz-Firewalls konfigurieren, um Aufrufservices zuzulassen

In diesem Abschnitt wird beschrieben, wie Sie die Instanzfirewallkonfiguration ändern und einen systemd-Service erstellen, um die Änderungen wiederherzustellen, wenn das System neu gestartet wird.

Firewallkonfiguration ändern

Ändern Sie als privilegierter Benutzer die Instanzfirewallkonfiguration, damit die Instanz auf Serviceendpunkte wie iaas und identity zugreifen kann.
Verwenden Sie den Befehl iptables, um die folgenden BareMetalInstanceServices-Regeln zur Instanzfirewall hinzuzufügen:
```
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
```
Der erste Eintrag ist für alle Endpunkte erforderlich. Der zweite Eintrag ist erforderlich, um den Object Storage-Endpunkt zu kontaktieren.

Konfigurationsänderungen dauerhaft speichern

Führen Sie die folgenden Schritte aus, damit diese Änderungen an der Firewallkonfiguration auch nach einem Neustart der Instanz beibehalten werden.

Speichern Sie die aktualisierte Konfiguration der IP-Tabellen.
```
iptables-save > /etc/sysconfig/iptables.rules
```
Erstellen Sie ein Skript, um die aktuelle (geänderte) Firewallkonfiguration beim Neustart automatisch wiederherzustellen.

In diesem Beispiel heißt das Skript /sbin/restore-iptables.sh. Der Inhalt der Datei /sbin/restore-iptables.sh lautet wie folgt:
```
#!/bin/sh
/sbin/iptables-restore < /etc/sysconfig/iptables.rules
```
Legen Sie das ausführbare Bit für das Skript fest.
```
chmod +x /sbin/restore-iptables.sh
```
Erstellen Sie einen systemd oneshot-Service, um das Skript /sbin/restore-iptables.sh beim Booten auszuführen.

In diesem Beispiel heißt der Service /etc/systemd/system/restore-iptables.service. Der Inhalt der Datei /etc/systemd/system/restore-iptables.service lautet wie folgt:
```
[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
```
Laden Sie die Managerkonfiguration systemd neu, und aktivieren Sie die Ausführung des Service beim Booten.
```
systemctl daemon-reload
systemctl enable restore-iptables
```

Instanzzertifikate so konfigurieren, dass aufrufende Services zulässig sind

Auf Compute Cloud@Customer bieten Endpunkte (wie iaas und identity) standardmäßig ein Zertifikat, das von einer für diese Compute Cloud@Customer spezifischen CA signiert wird. Standardmäßig vertrauen Betriebssysteme Zertifikaten nicht, die von einer CA signiert wurden, die für diese Compute Cloud@Customer spezifisch ist. Wenn das BS den angebotenen Zertifikaten nicht vertraut, verläuft der Versuch, das OCI-SDK oder die CLI zu verwenden, nicht erfolgreich. Fehler: CERTIFICATE_VERIFY_FAILED.

Implementieren Sie eine der in diesem Thema beschriebenen Lösungen, um das OCI-SDK oder die CLI erfolgreich in der Instanz zu verwenden.

Wichtig

Jeder Benutzer, der eine SSH-Verbindung zur Instanz herstellen kann, erbt automatisch die Berechtigungen, die der Instanz erteilt wurden.

Option 1: Bring Your Own Zertifikat (BYOC)

Auf Compute Cloud@Customer können Sie Ihre eigenen CA-Zertifikate (Certificate Authority, CA) bereitstellen, mit denen Sie Ihre CA-Trust Chain verwenden können. Um Ihre eigenen Zertifikate zu verwenden, öffnen Sie eine Supportanfrage und fordern Sie die Verwendung Ihrer eigenen Zertifikate an. Siehe Supportanfrage erstellen. Um auf Support zuzugreifen, melden Sie sich bei der Oracle Cloud-Konsole an, wie unter Bei der OCI-Konsole anmelden beschrieben.

Bei einem Linux-Betriebssystem führt der folgende Befehl standardmäßig vertrauenswürdige CAs auf:

trust list --filter=ca-anchors

Option 2: Geben Sie im SDK-Code das zu verwendende CA-Bundle an

Mit dieser Methode wird das Compute Cloud@Customer-spezifische CA-Bundle in die Instanz kopiert, das Serverzertifikat (--insecure) wird jedoch nicht geprüft. Um die Sicherheit zu gewährleisten, prüfen Sie den Inhalt des abgerufenen Bundles (external_ca.crt).

Rufen Sie das Zertifikat vom iaas-Endpunkt von Compute Cloud@Customer ab.
```
curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.ccc_name.domain_name/cachain
```
Dieser Befehl kann sich in einem Skript befinden, das zur Startzeit an die Instanz übergeben wird, indem entweder die Option --user-data-file oder die Option --metadata mit dem Feld user_data verwendet wird. Das Skript wird während der Initialisierung von cloud-init innerhalb der Instanz ausgeführt. Dadurch wird der Aufwand vermieden, diese Zertifikatsdatei auf vielen Instanzen manuell abzurufen.
Prüfen Sie den Inhalt des CA-Bundles, das in der Datei external_ca.crt gespeichert ist.

Geben Sie das CA-Bundle im Python-SDK-Code an.

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: Globales Vertrauen in das CA-Bundle Compute Cloud@Customer

Diese Methode entspricht der vorherigen Methode mit dem folgenden Unterschied: Anstatt das CA-Bundle im SDK-Code anzugeben, fügt diese Methode das CA-Bundle zur Trust Chain hinzu.

Wichtig

Wenn das CA-Bundle zur Trust Chain hinzugefügt wird, vertraut jede Anwendung auf dieser Compute-Instanz Zertifikaten, die mit der in diesem Bundle angegebenen CA signiert sind. Überlegen Sie, ob dies ein akzeptables Sicherheitsrisiko ist.

Rufen Sie das Zertifikat vom iaas-Endpunkt von Compute Cloud@Customer ab.

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

Prüfen Sie den Inhalt des CA-Bundles, das in der Datei external_ca.crt gespeichert ist.

Aktualisieren Sie die globale CA-Vertrauungskette.

cp external_ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust extract

Die Schritte 1 und 3 in dieser Methode können in einem Skript enthalten sein, das zur Startzeit an die Instanz übergeben wird, indem entweder die Option --user-data-file oder die Option --metadata mit einem Feld user_data verwendet wird. Das Skript wird während der Initialisierung durch cloud-init innerhalb der Instanz ausgeführt. Dadurch wird der Aufwand für die manuelle Ausführung dieser Schritte auf vielen Instanzen gespart.