Oracle Cloud Infrastructure-Dokumentation

Instanzen für den Aufruf von Services konfigurieren

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

Ein Instanz-Principal ist eine Compute-Instanz, die autorisiert ist, Aktionen für Serviceressourcen auszuführen. Anwendungen, die auf einem Instanz-Principal ausgeführt werden, können Services aufrufen und Ressourcen verwalten, ähnlich wie Oracle Roving Edge-Benutzer Services zum Verwalten von Ressourcen aufrufen. Die Instanz ist ein Hauptakteur, genauso wie ein Benutzer ein Hauptakteur ist. Wenn Sie Instanz-Principals verwenden, müssen Sie keine Benutzerzugangsdaten oder eine Konfigurationsdatei auf der Instanz konfigurieren, um Anwendungen auszuführen, die Dienstressourcen verwalten müssen.

Um einem Instanz-Principal Autorisierungen zu erteilen, nehmen Sie die Instanz als Mitglied einer dynamischen Gruppe auf. Eine dynamische Gruppe stellt Instanzen Autorisierungen bereit, ebenso wie eine Benutzergruppe Benutzern Autorisierungen bereitstellt.

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 enthalten ist, die Berechtigungen für den Zugriff auf die erforderlichen Ressourcen erteilt. Siehe Dynamische Gruppen erstellen und 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 schreiben.

Instanz-Firewalls konfigurieren, um Aufrufservices zuzulassen

In diesem Thema 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.

  1. Speichern Sie die aktualisierte Konfiguration der IP-Tabellen.

    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 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

Standardmäßig bieten Roving Edge-Endpunkte (wie iaas und identity) ein Zertifikat, das von einer für dieses Gerät spezifischen CA signiert wird. Standardmäßig vertrauen Betriebssystemen Zertifikaten nicht, die von einer CA signiert wurden, die für diese Roving Edge 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.

Hinweis

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)

Wenn Sie ein Zertifikat haben, das von einer CA signiert wurde, der Ihr BS vertraut, konfigurieren Sie Roving Edge so, dass es dieses Zertifikat anbietet.

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

trust list --filter=ca-anchors

Informationen zum Bereitstellen eines eigenen Zertifikats finden Sie unter "Auf externe Schnittstellen mit Ihrer CA-Vertrauenskette zugreifen".

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

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

  1. Rufen Sie das Zertifikat vom iaas-Endpunkt der Appliance ab.

    curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_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 manuell auf einer großen Anzahl von Instanzen abzurufen.

  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 Roving Edge CA Bundle

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.

Hinweis

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.

  1. Rufen Sie das Zertifikat vom iaas-Endpunkt der Appliance ab.

    curl --insecure -sS -o external_ca.crt --noproxy "*" https://iaas.pca_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-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 von cloud-init innerhalb der Instanz ausgeführt, wodurch der Aufwand für die manuelle Ausführung dieser Schritte bei einer großen Anzahl von Instanzen eingespart wird.

Python-SDK und -CLI für Instanz-Principals konfigurieren

In diesem Thema wird beschrieben, wie Sie die Instanz-Principal-Autorisierung für das Python-SDK, die CLI oder Terraform aktivieren.

Instanz-Principal-Autorisierung für das Python-SDK aktivieren

Erstellen Sie in Ihrem SDK für Python ein oci.auth.signers.InstancePrincipalsSecurityTokenSigner-Objekt, wie im folgenden Beispiel dargestellt:

# 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)

Um das Token ohne Wartezeit zu aktualisieren, verwenden Sie den folgenden Befehl:

signer.refresh_security_token()

Autorisierung des Instanz-Principals für die CLI aktivieren

Legen Sie die Autorisierungsoption (--auth) für einen Befehl fest, wie im folgenden Beispiel dargestellt:

oci os ns get --auth instance_principal

Alternativ können Sie die folgende Umgebungsvariable festlegen:

OCI_CLI_AUTH=instance_principal

Wenn beide Werte festgelegt sind, hat der für --auth festgelegte Wert Vorrang vor der Umgebungsvariable.

Autorisierung des Instanz-Principals für Terraform aktivieren

Legen Sie das Attribut auth in der Providerdefinition auf "InstancePrincipal" fest, wie im folgenden Fall dargestellt:

variable "region" {}

provider "oci" {
   auth = "InstancePrincipal"  
   region = "${var.region}"

}

Wenn Sie eine Instanz-Principal-Autorisierung verwenden, müssen Sie nicht die Attribute tenancy_ocid, user_ocid, fingerprint und private_key_path aufnehmen.