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 zur Verwaltung von Ressourcen aufrufen.

Das IAM-Servicefeature, mit dem Instanzen als autorisierte Akteure (oder Principals) Aktionen an Serviceressourcen 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 Instanzfirewalls zum Aufrufen von Services konfigurieren.

  • Stellen Sie sicher, dass die Instanz in einer dynamischen Gruppe enthalten ist (in Ihrem Mandanten konfiguriert), 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. Siehe Abgleichsregeln zum Definieren dynamischer Gruppen schreiben.

Instanzfirewalls konfigurieren, um den Aufruf von Services 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
  1. Ändern Sie als privilegierter Benutzer die Instanzfirewallkonfiguration, damit die Instanz auf Serviceendpunkte wie iaas und identity zugreifen kann.

  2. Verwenden Sie den Befehl iptables, um der Instanzfirewall die folgenden BareMetalInstanceServices-Regeln 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.

Ändern Sie die Konfiguration dauerhaft,

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

  1. Speichern Sie die aktualisierte IP-Tabellenkonfiguration.

    iptables-save > /etc/sysconfig/iptables.rules
  2. 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
  3. Legen Sie das ausführbare Bit für das Skript fest.

    chmod +x /sbin/restore-iptables.sh
  4. 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
  5. Laden Sie die systemd-Manager-Konfiguration neu, und aktivieren Sie die Ausführung des Service beim Booten.

    systemctl daemon-reload
    systemctl enable restore-iptables

Instanzzertifikate zum Aufrufen von Services konfigurieren

Auf Compute Cloud@Customer bieten Endpunkte (wie iaas und identity) standardmäßig ein Zertifikat an, das von einer CA signiert wird, die für diese Compute Cloud@Customer spezifisch ist. Standardmäßig vertrauen BSs Zertifikaten nicht, die von einer CA signiert sind, 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, mit einem CERTIFICATE_VERIFY_FAILED-Fehler nicht erfolgreich.

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

Wichtig

Jeder Benutzer, der mit SSH auf die Instanz zugreifen kann, erbt automatisch die Berechtigungen, die der Instanz erteilt wurden.

Option 1: Bring Your Own Certificate (BYOC)

Auf Compute Cloud@Customer können Sie Ihre eigenen Certificate Authority-(CA-)Zertifikate 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 den Support zuzugreifen, melden Sie sich bei der Oracle Cloud-Konsole an, wie unter Bei OCI-Konsole anmelden beschrieben.

Bei einem Linux-BS listet 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

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

  1. Rufen Sie das Zertifikat vom Endpunkt iaas der Compute Cloud@Customer-Infrastruktur 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 zum Startzeitpunkt 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 des Initialisierungsvorgangs von cloud-init innerhalb der Instanz ausgeführt. Dadurch wird der Aufwand für das manuelle Abrufen dieser Zertifikatsdatei auf vielen Instanzen gespeichert.

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

  3. 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 von Oracle 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 der Trust Chain hinzu.

Wichtig

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

  1. Rufen Sie das Zertifikat vom Endpunkt iaas der Compute Cloud@Customer-Infrastruktur ab.

    curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.ccc_name.domain_name/cachain
  2. Prüfen Sie den Inhalt des CA-Bundles, das in der Datei external_ca.crt gespeichert ist.

  3. Aktualisieren Sie die globale CA-Vertrauenskette.

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

Die Schritte 1 und 3 in dieser Methode können sich in einem Skript befinden, das beim Start entweder mit der Option --user-data-file oder der Option --metadata mit einem Feld user_data an die Instanz übergeben wird. Das Skript wird während des Initialisierungsvorgangs nach cloud-init innerhalb der Instanz ausgeführt. Dadurch wird der Aufwand für die manuelle Ausführung dieser Schritte auf vielen Instanzen gespart.