Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Erstellen Sie einen ROSA klassischen Cluster, der AWS PrivateLink
ROSAklassische Cluster können auf verschiedene Arten bereitgestellt werden: öffentlich, privat oder privat mit AWS PrivateLink. Weitere Informationen zu ROSA Classic finden Sie unterArchitekturmodelle. Sowohl bei öffentlichen als auch bei privaten Cluster Konfigurationen OpenShift Cluster hat der Zugriff auf das Internet, und der Datenschutz für die Anwendungs-Workloads wird auf der Anwendungsebene festgelegt.
Wenn Cluster sowohl die Workloads als auch die Anwendungs-Workloads privat sein müssen, können Sie sie AWS PrivateLink mit ROSA Classic konfigurieren. AWS PrivateLink ist eine hochverfügbare, skalierbare Technologie, ROSA mit der eine private Verbindung zwischen den ROSA Service- und Clusterressourcen im AWS Kundenkonto hergestellt wird. Damit AWS PrivateLink kann das RedHat Site Reliability Engineering (SRE) -Team zu Support- und Problembehebungszwecken auf den Cluster zugreifen, indem es ein privates Subnetz verwendet, das mit dem Endpunkt des Clusters verbunden ist AWS PrivateLink .
Weitere Informationen zu finden Sie AWS PrivateLink unter Was ist? AWS PrivateLink
Themen
- Voraussetzungen
- Erstellen Sie eine Amazon VPC Architektur für den Cluster
- Erstellen Sie einen ROSA klassischen Cluster mit dem ROSA CLI und AWS PrivateLink
- Konfigurieren Sie die AWS PrivateLink DNS Weiterleitung
- Konfigurieren Sie einen Identitätsanbieter und gewähren Cluster Sie Zugriff
- Gewähren Sie dem Benutzer Zugriff auf eine Cluster
- cluster-adminBerechtigungen konfigurieren
- dedicated-adminBerechtigungen konfigurieren
- Greifen Sie Cluster über die Red Hat Hybrid Cloud Console auf a zu
- Stellen Sie eine Anwendung aus dem Entwicklerkatalog bereit
- Widerrufen cluster-admin Sie die Berechtigungen eines Benutzers
- Widerrufen dedicated-admin Sie die Berechtigungen eines Benutzers
- Widerrufen Sie den Benutzerzugriff auf eine Cluster
- Löschen Sie einen Cluster und AWS STS Ressourcen
Voraussetzungen
Führen Sie die erforderlichen Aktionen aus, die unter aufgeführt sindZur Verwendung eingerichtet ROSA.
Erstellen Sie eine Amazon VPC Architektur für den Cluster
Um eine zu erstellen, ROSA Cluster die verwendet AWS PrivateLink, müssen Sie zunächst Ihre eigene Amazon VPC Architektur konfigurieren, in der Ihre Lösung bereitgestellt werden soll. Das folgende Verfahren verwendet die AWS CLI , um sowohl ein öffentliches als auch ein privates Subnetz in einer einzigen Availability Zone für einen Single-AZ-Cluster zu erstellen. Alle Cluster Ressourcen befinden sich im privaten Subnetz. Das öffentliche Subnetz leitet ausgehenden Verkehr über ein NAT Gateway zum Internet weiter.
In diesem Beispiel wird der CIDR Block 10.0.0.0/16
für die verwendet. Amazon VPC Sie können jedoch einen anderen CIDR Block wählen. Weitere Informationen finden Sie unter VPCGröße.
Wichtig
Wenn die Amazon VPC Anforderungen nicht erfüllt werden, schlägt die Clustererstellung fehl.
-
Legen Sie eine Umgebungsvariable für den Cluster Namen fest, indem Sie den folgenden Befehl ausführen.
ROSA_CLUSTER_NAME=rosa-hcp
-
Erstellen Sie eine VPC mit einem
10.0.0.0/16
CIDR Block.aws ec2 create-vpc --cidr-block 10.0.0.0/16 --query Vpc.VpcId --output text
Der vorherige Befehl gibt die ID des neuen zurückVPC. Im Folgenden finden Sie eine Beispielausgabe.
vpc-0410832ee325aafea
-
Verwenden Sie die VPC ID aus dem vorherigen Schritt und kennzeichnen VPC Sie das mithilfe der
ROSA_CLUSTER_NAME
Variablen.aws ec2 create-tags --resources <VPC_ID_VALUE> --tags Key=Name,Value=$ROSA_CLUSTER_NAME
-
Aktivieren Sie die DNS Hostnamen-Unterstützung auf demVPC.
aws ec2 modify-vpc-attribute --vpc-id <VPC_ID_VALUE> --enable-dns-hostnames
-
Erstellen Sie ein öffentliches Subnetz VPC mit einem
10.0.1.0/24
CIDR Block und geben Sie die Availability Zone an, in der die Ressource erstellt werden soll.Wichtig
ROSAmit HCP erfordert, dass Kunden mindestens ein öffentliches und ein privates Subnetz pro Availability Zone konfigurieren, die zum Erstellen von Clustern verwendet wird. Für Single-AZ-Cluster wird nur eine Availability Zone benötigt. Für Multi-AZ-Cluster sind drei Availability Zones erforderlich. Wenn diese Anforderungen nicht erfüllt sind, schlägt die Clustererstellung fehl.
Anmerkung
Achten Sie beim Erstellen von Subnetzen darauf, dass Subnetze für eine Availability Zone erstellt werden, in der ROSA Instanztypen verfügbar sind. Wenn Sie keine bestimmte Availability Zone auswählen, wird das Subnetz in einer der Availability Zones in der von Ihnen angegebenen Availability Zone erstellt. AWS-Region
Verwenden Sie das
--availability zone
Argument imcreate-subnet
Befehl, um eine bestimmte Availability Zone anzugeben. Sie können denrosa list instance-types
Befehl verwenden, um alle verfügbaren ROSA Instance-Typen aufzulisten. Verwenden Sie den folgenden Befehl, um zu überprüfen, ob ein Instance-Typ für eine bestimmte Availability Zone verfügbar ist.aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=location,Values=<availability_zone> --region <region> --output text | egrep "<instance_type>"
aws ec2 create-subnet --vpc-id <VPC_ID_VALUE> --cidr-block 10.0.1.0/24 --availability-zone <AZ_NAME> --query Subnet.SubnetId --output text
Der vorherige Befehl gibt die ID des neuen Subnetzes zurück. Im Folgenden finden Sie eine Beispielausgabe.
subnet-0b6a7e8cbc8b75920
-
Verwenden Sie die Subnetz-ID aus dem vorherigen Schritt und kennzeichnen Sie das Subnetz mithilfe der Variablen.
ROSA_CLUSTER_NAME-public
aws ec2 create-tags --resources <PUBLIC_SUBNET_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME-public
-
Erstellen Sie ein privates Subnetz im Block VPC mit einem
10.0.0.0/24
CIDR Block und geben Sie dabei dieselbe Availability Zone an, in der das öffentliche Subnetz bereitgestellt wurde.aws ec2 create-subnet --vpc-id <VPC_ID_VALUE> --cidr-block 10.0.0.0/24 --availability-zone <AZ_NAME> --query Subnet.SubnetId --output text
Der vorherige Befehl gibt die ID des neuen Subnetzes zurück. Im Folgenden finden Sie eine Beispielausgabe.
subnet-0b6a7e8cbc8b75920
-
Verwenden Sie die Subnetz-ID aus dem vorherigen Schritt und kennzeichnen Sie das Subnetz mithilfe der Variablen.
ROSA_CLUSTER_NAME-private
aws ec2 create-tags --resources <PRIVATE_SUBNET_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME-private
-
Erstellen Sie ein Internet-Gateway für ausgehenden Verkehr und verbinden Sie es mit dem. VPC
aws ec2 create-internet-gateway --query InternetGateway.InternetGatewayId --output text aws ec2 attach-internet-gateway --vpc-id <VPC_ID_VALUE> --internet-gateway-id <IG_ID_VALUE>
-
Kennzeichnen Sie das Internet-Gateway mit der
ROSA_CLUSTER_NAME
Variablen.aws ec2 create-tags --resources <IG_ID_VALUE> --tags Key=Name,Value=$ROSA_CLUSTER_NAME
-
Erstellen Sie eine Routing-Tabelle für ausgehenden Verkehr, ordnen Sie sie dem öffentlichen Subnetz zu und konfigurieren Sie den Verkehr so, dass er zum Internet-Gateway weitergeleitet wird.
aws ec2 create-route-table --vpc-id <VPC_ID_VALUE> --query RouteTable.RouteTableId --output text aws ec2 associate-route-table --subnet-id <PUBLIC_SUBNET_ID> --route-table-id <PUBLIC_RT_ID> aws ec2 create-route --route-table-id <PUBLIC_RT_ID> --destination-cidr-block 0.0.0.0/0 --gateway-id <IG_ID_VALUE>
-
Kennzeichnen Sie die öffentliche Routing-Tabelle mit der
ROSA_CLUSTER_NAME
Variablen und stellen Sie sicher, dass die Routing-Tabelle ordnungsgemäß konfiguriert wurde.aws ec2 create-tags --resources <PUBLIC_RT_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME aws ec2 describe-route-tables --route-table-id <PUBLIC_RT_ID>
-
Erstellen Sie ein NAT Gateway im öffentlichen Subnetz mit einer elastischen IP-Adresse, um den Verkehr zum privaten Subnetz zu ermöglichen.
aws ec2 allocate-address --domain vpc --query AllocationId --output text aws ec2 create-nat-gateway --subnet-id <PUBLIC_SUBNET_ID> --allocation-id <EIP_ADDRESS> --query NatGateway.NatGatewayId --output text
-
Kennzeichnen Sie das NAT Gateway und die elastische IP-Adresse mit der
$ROSA_CLUSTER_NAME
Variablen.aws ec2 create-tags --resources <EIP_ADDRESS> --resources <NAT_GATEWAY_ID> --tags Key=Name,Value=$ROSA_CLUSTER_NAME
-
Erstellen Sie eine Routing-Tabelle für privaten Subnetzverkehr, ordnen Sie sie dem privaten Subnetz zu und konfigurieren Sie den Verkehr so, dass er zum NAT Gateway weitergeleitet wird.
aws ec2 create-route-table --vpc-id <VPC_ID_VALUE> --query RouteTable.RouteTableId --output text aws ec2 associate-route-table --subnet-id <PRIVATE_SUBNET_ID> --route-table-id <PRIVATE_RT_ID> aws ec2 create-route --route-table-id <PRIVATE_RT_ID> --destination-cidr-block 0.0.0.0/0 --gateway-id <NAT_GATEWAY_ID>
-
Kennzeichnen Sie die private Routentabelle und die elastische IP-Adresse mit der
$ROSA_CLUSTER_NAME-private
Variablen.aws ec2 create-tags --resources <PRIVATE_RT_ID> <EIP_ADDRESS> --tags Key=Name,Value=$ROSA_CLUSTER_NAME-private
Erstellen Sie einen ROSA klassischen Cluster mit dem ROSA CLI und AWS PrivateLink
Sie können ROSA CLI und {privatelinkg} verwenden, um eine Cluster mit einer einzigen Availability Zone (Single-AZ) oder mehreren Availability Zones (Multi-AZ) zu erstellen. In beiden Fällen muss der Wert Ihrer Maschine Ihrem CIDR Wert entsprechen. VPC CIDR
Im folgenden Verfahren wird der rosa create cluster
Befehl verwendet, um eine Single-AZ ROSA
Cluster zu erstellen. Um eine Multi-AZ zu erstellen Cluster, geben Sie multi-az
im Befehl das private Subnetz IDs für jedes private Subnetz an, in dem Sie die Bereitstellung durchführen möchten.
Anmerkung
Wenn Sie eine Firewall verwenden, müssen Sie sie so konfigurieren, dass sie auf die Websites zugreifen ROSA kann, die für ihren Betrieb erforderlich sind.
Weitere Informationen finden Sie unter AWS Firewall-Voraussetzungen
-
Erstellen Sie eine Single-AZ, Cluster indem Sie den folgenden Befehl ausführen.
rosa create cluster --private-link --cluster-name=<CLUSTER_NAME> --machine-cidr=10.0.0.0/16 --subnet-ids=<PRIVATE_SUBNET_ID>
Anmerkung
Um einen Cluster zu erstellen, der AWS PrivateLink mit AWS Security Token Service (AWS STS) kurzlebige Anmeldeinformationen verwendet, fügen Sie
--sts --mode auto
oder--sts --mode manual
an das Ende des Befehls an.rosa create cluster
-
Erstellen Sie die Cluster IAM Operatorrollen, indem Sie den interaktiven Anweisungen folgen.
rosa create operator-roles --interactive -c <CLUSTER_NAME>
-
Erstellen Sie den OpenID Connect (OIDC) -Anbieter, den die Cluster Operatoren zur Authentifizierung verwenden.
rosa create oidc-provider --interactive -c <CLUSTER_NAME>
-
Überprüfen Sie den Status Ihres. Cluster
rosa describe cluster -c <CLUSTER_NAME>
Anmerkung
Es kann bis zu 40 Minuten dauern, bis das Cluster
State
Feld denready
Status anzeigt. Wenn die Bereitstellung fehlschlägt oder nichtready
nach 40 Minuten angezeigt wird, finden Sie weitere Informationen unterFehlerbehebung.Wenn Sie Hilfe benötigen AWS Support oder den Red Hat Support kontaktieren möchten, finden Sie unterROSA Unterstützung erhalten.
-
Verfolgen Sie den Fortschritt der Cluster Erstellung, indem Sie sich die OpenShift Installationsprotokolle ansehen.
rosa logs install -c <CLUSTER_NAME> --watch
Konfigurieren Sie die AWS PrivateLink DNS Weiterleitung
Cluster, die verwenden, AWS PrivateLink erstellen eine öffentliche gehostete Zone und eine private gehostete Zone in Route 53. Datensätze innerhalb der Route 53 privaten Hosting-Zone können nur innerhalb der Zone aufgelöst werdenVPC, der sie zugewiesen sind.
Für die Validierung von Let's Encrypt DNS -01 ist eine öffentliche Zone erforderlich, damit gültige und öffentlich vertrauenswürdige Zertifikate für die Domain ausgestellt werden können. Die Validierungsdatensätze werden gelöscht, nachdem die Let's Encrypt-Validierung abgeschlossen ist. Die Zone ist weiterhin für die Ausstellung und Erneuerung dieser Zertifikate erforderlich, die normalerweise alle 60 Tage erforderlich sind. Obwohl diese Zonen normalerweise leer erscheinen, spielt eine öffentliche Zone eine entscheidende Rolle im Validierungsprozess.
Weitere Informationen zu AWS privaten gehosteten Zonen finden Sie unter Arbeiten mit privaten Zonen. Weitere Informationen zu öffentlich gehosteten Zonen finden Sie unter Arbeiten mit öffentlich gehosteten Zonen.
Konfigurieren Sie einen Route 53 Resolver eingehenden Endpunkt
Konfigurieren Sie einen Route 53 Resolver Eingangsendpunkt*.apps.<cluster_domain>
, um Datensätze wie z. B. zu ermöglichen api.<cluster_domain>
und die VPC Auflösung außerhalb von zu ermöglichen.
-
Öffnen Sie die Route 53 Konsole.
-
Wählen Sie im Navigationsbereich unter Resolver die Option Inbound Endpoints aus.
-
Wählen Sie Endpunkte konfigurieren aus.
-
Verwenden Sie oben rechts den AWS-Region Selektor, um den auszuwählen AWS-Region , der die für den Cluster VPC verwendeten enthält.
-
Wählen Sie unter Grundkonfiguration die Option Nur eingehend und dann Weiter aus.
-
Füllen Sie auf der Seite „Eingehenden Endpunkt konfigurieren“ den Abschnitt Allgemeine Einstellungen für eingehenden Endpunkt aus. Wählen Sie unter Sicherheitsgruppe für diesen Endpunkt eine Sicherheitsgruppe aus, die eingehenden UDP und vom Remote-Netzwerk ausgehenden TCP Datenverkehr am Zielport 53 zulässt.
-
Wählen Sie im Abschnitt IP-Adresse die Availability Zones und privaten Subnetze aus, die bei der Erstellung des Clusters verwendet wurden, und klicken Sie auf Weiter.
-
(Optional) Füllen Sie den Abschnitt „Tags“ aus.
-
Wählen Sie Absenden aus.
Konfigurieren Sie die DNS Weiterleitung für den Cluster
Nachdem der Route 53 Resolver interne Endpunkt zugeordnet und betriebsbereit ist, konfigurieren Sie die DNS Weiterleitung, sodass DNS Anfragen von den dafür vorgesehenen Servern in Ihrem Netzwerk bearbeitet werden können.
-
Konfigurieren Sie Ihr Unternehmensnetzwerk so, dass DNS Anfragen an die IP-Adressen für die Top-Level-Domain weitergeleitet werden, z. B.
drow-pl-01.htno.p1.openshiftapps.com
-
Wenn Sie DNS Anfragen von einem Server VPC an einen anderen weiterleitenVPC, folgen Sie den Anweisungen unter Weiterleitungsregeln verwalten.
-
Wenn Sie Ihren DNS Remote-Netzwerkserver konfigurieren, finden Sie in der jeweiligen DNS Serverdokumentation Informationen zur Konfiguration der selektiven DNS Weiterleitung für die installierte Clusterdomäne.
Konfigurieren Sie einen Identitätsanbieter und gewähren Cluster Sie Zugriff
ROSA beinhaltet einen integrierten OAuth Server. Nachdem Sie Ihren ROSA
Cluster erstellt haben, müssen Sie ihn OAuth für die Verwendung eines Identitätsanbieters konfigurieren. Anschließend können Sie Benutzer zu Ihrem konfigurierten Identitätsanbieter hinzufügen, um ihnen Zugriff auf Ihren zu gewähren Cluster. Sie können diesen Benutzern cluster-admin
oder dedicated-admin
Berechtigungen nach Bedarf gewähren.
Sie können verschiedene Identitätsanbietertypen für Ihren konfigurieren Cluster. Zu den unterstützten Typen gehören GitHub Enterprise GitHub GitLab, GoogleLDAP, OpenID Connect und HTPasswd Identity Providers.
Wichtig
Der HTPasswd Identitätsanbieter ist nur enthalten, um die Erstellung eines einzelnen statischen Administratorbenutzers zu ermöglichen. HTPasswdwird nicht als allgemein verwendbarer Identitätsanbieter für unterstützt. ROSA
Das folgende Verfahren konfiguriert als Beispiel einen GitHub Identitätsanbieter. Anweisungen zur Konfiguration der einzelnen unterstützten Identitätsanbietertypen finden Sie unter Konfiguration von Identitätsanbietern für AWS STS
-
Navigieren Sie zu github.com
und melden Sie sich bei Ihrem GitHub Konto an. -
Wenn Sie keine GitHub Organisation haben, die Sie für die Identitätsbereitstellung verwenden können ROSA Cluster, erstellen Sie eine. Weitere Informationen finden Sie in den Schritten in der GitHub Dokumentation
. -
Konfigurieren Sie im interaktiven Modus einen Identitätsanbieter für Ihren Cluster, indem Sie den folgenden Befehl ausführen. ROSA CLI
rosa create idp --cluster=<CLUSTER_NAME> --interactive
-
Folgen Sie den Konfigurationsanweisungen in der Ausgabe, um den Cluster Zugriff auf Mitglieder Ihrer GitHub Organisation zu beschränken.
I: Interactive mode enabled. Any optional fields can be left empty and a default will be selected. ? Type of identity provider: github ? Identity provider name: github-1 ? Restrict to members of: organizations ? GitHub organizations: <GITHUB_ORG_NAME> ? To use GitHub as an identity provider, you must first register the application: - Open the following URL: https://github.com/organizations/<GITHUB_ORG_NAME>/settings/applications/new?oauth_application%5Bcallback_url%5D=https%3A%2F%2Foauth-openshift.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com%2Foauth2callback%2Fgithub-1&oauth_application%5Bname%5D=<CLUSTER_NAME>&oauth_application%5Burl%5D=https%3A%2F%2Fconsole-openshift-console.apps.<CLUSTER_NAME>/<RANDOM_STRING>.p1.openshiftapps.com - Click on 'Register application' ...
-
Öffnen Sie das URL in der Ausgabe und
<GITHUB_ORG_NAME>
ersetzen Sie es durch den Namen Ihrer GitHub Organisation. -
Wählen Sie auf der GitHub Webseite Anwendung registrieren aus, um eine neue OAuth Anwendung in Ihrer GitHub Organisation zu registrieren.
-
Verwenden Sie die Informationen GitHub OAuth auf der Seite, um die verbleibenden
rosa create idp
interaktiven Eingabeaufforderungen zu füllen,<GITHUB_CLIENT_ID>
und<GITHUB_CLIENT_SECRET>
ersetzen Sie dabei die Anmeldeinformationen aus Ihrer GitHub OAuth Anwendung.... ? Client ID: <GITHUB_CLIENT_ID> ? Client Secret: [? for help] <GITHUB_CLIENT_SECRET> ? GitHub Enterprise Hostname (optional): ? Mapping method: claim I: Configuring IDP for cluster '<CLUSTER_NAME>' I: Identity Provider 'github-1' has been created. It will take up to 1 minute for this configuration to be enabled. To add cluster administrators, see 'rosa grant user --help'. To login into the console, open https://console-openshift-console.apps.<CLUSTER_NAME>.<RANDOM_STRING>.p1.openshiftapps.com and click on github-1.
Anmerkung
Es kann etwa zwei Minuten dauern, bis die Identity Provider-Konfiguration aktiv wird. Wenn Sie einen
cluster-admin
Benutzer konfiguriert haben, können Sie denoc get pods -n openshift-authentication --watch
Befehl ausführen, um zu beobachten, wie die OAuth Pods mit der aktualisierten Konfiguration erneut bereitgestellt werden. -
Stellen Sie sicher, dass der Identitätsanbieter korrekt konfiguriert wurde.
rosa list idps --cluster=<CLUSTER_NAME>
Gewähren Sie dem Benutzer Zugriff auf eine Cluster
Sie können einem Benutzer Zugriff auf Ihre gewähren, Cluster indem Sie ihn dem konfigurierten Identitätsanbieter hinzufügen.
Das folgende Verfahren fügt einen Benutzer zu einer GitHub Organisation hinzu, die für die Identitätsbereitstellung im Cluster konfiguriert ist.
-
Navigieren Sie zu github.com
und melden Sie sich bei Ihrem GitHub Konto an. -
Laden Sie Benutzer ein, die Cluster Zugriff auf Ihre GitHub Organisation benötigen. Weitere Informationen finden Sie in der GitHub Dokumentation unter Benutzer einladen, Ihrer Organisation
beizutreten.
cluster-admin
Berechtigungen konfigurieren
-
Erteilen Sie die
cluster-admin
Berechtigungen mit dem folgenden Befehl. Ersetzen Sie<IDP_USER_NAME>
und<CLUSTER_NAME>
durch Ihren Benutzer- und Clusternamen.rosa grant user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
-
Stellen Sie sicher, dass der Benutzer als Mitglied der
cluster-admins
Gruppe aufgeführt ist.rosa list users --cluster=<CLUSTER_NAME>
dedicated-admin
Berechtigungen konfigurieren
-
Erteilen Sie die
dedicated-admin
Berechtigungen mit dem folgenden Befehl. Ersetzen Sie<IDP_USER_NAME>
und<CLUSTER_NAME>
durch Ihren Benutzer und Cluster Namen.rosa grant user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
-
Stellen Sie sicher, dass der Benutzer als Mitglied der
cluster-admins
Gruppe aufgeführt ist.rosa list users --cluster=<CLUSTER_NAME>
Greifen Sie Cluster über die Red Hat Hybrid Cloud Console auf a zu
Nachdem Sie einen Cluster Administratorbenutzer erstellt oder einen Benutzer zu Ihrem konfigurierten Identity Provider hinzugefügt haben, können Sie sich Cluster über die Red Hat Hybrid Cloud Console bei Ihrem anmelden.
-
Rufen Sie die Konsole URL für Sie Cluster mit dem folgenden Befehl ab.
<CLUSTER_NAME>
Ersetzen Sie durch den Namen Ihres Cluster.rosa describe cluster -c <CLUSTER_NAME> | grep Console
-
Navigieren Sie URL in der Ausgabe zur Konsole und melden Sie sich an.
-
Wenn Sie einen
cluster-admin
Benutzer erstellt haben, melden Sie sich mit den angegebenen Anmeldeinformationen an. -
Wenn Sie einen Identitätsanbieter für Ihren konfiguriert haben Cluster, wählen Sie den Namen des Identitätsanbieters im Dialogfeld Anmelden mit... und füllen Sie alle Autorisierungsanfragen Ihres Anbieters aus.
-
Stellen Sie eine Anwendung aus dem Entwicklerkatalog bereit
Von der Red Hat Hybrid Cloud Console aus können Sie eine Developer Catalog-Testanwendung bereitstellen und sie mit einer Route verfügbar machen.
-
Navigieren Sie zur Red Hat Hybrid Cloud Console
und wählen Sie den Cluster aus, in dem Sie die App bereitstellen möchten. -
Wählen Sie auf der Seite des Clusters Open Console aus.
-
Wählen Sie in der Administratorperspektive Startseite > Projekte > Projekt erstellen aus.
-
Geben Sie einen Namen für Ihr Projekt ein und fügen Sie optional einen Anzeigenamen und eine Beschreibung hinzu.
-
Wählen Sie Erstellen, um das Projekt zu erstellen.
-
Wechseln Sie zur Entwicklerperspektive und wählen Sie +Hinzufügen. Stellen Sie sicher, dass das ausgewählte Projekt das ist, das gerade erstellt wurde.
-
Wählen Sie im Dialogfeld „Entwicklerkatalog“ die Option Alle Dienste aus.
-
Wählen Sie auf der Seite mit dem Entwicklerkatalog im Menü Sprachen > JavaScriptaus.
-
Wählen Sie Node.js und dann Anwendung erstellen, um die Seite „Source-to-Image-Anwendung erstellen“ zu öffnen.
Anmerkung
Möglicherweise müssen Sie Alle Filter löschen auswählen, um die Option Node.js anzuzeigen.
-
Wählen Sie im Abschnitt Git die Option Try Sample aus.
-
Fügen Sie im Feld Name einen eindeutigen Namen hinzu.
-
Wählen Sie Erstellen.
Anmerkung
Die Bereitstellung der neuen Anwendung dauert mehrere Minuten.
-
Wenn die Bereitstellung abgeschlossen ist, wählen Sie die Route URL für die Anwendung aus.
Im Browser wird eine neue Registerkarte mit einer Meldung geöffnet, die der folgenden ähnelt.
Welcome to your Node.js application on OpenShift
-
(Optional) Löschen Sie die Anwendung und bereinigen Sie die Ressourcen.
-
Wählen Sie in der Administratorperspektive „Startseite“ > „Projekte“.
-
Öffnen Sie das Aktionsmenü für Ihr Projekt und wählen Sie Projekt löschen.
-
Widerrufen cluster-admin
Sie die Berechtigungen eines Benutzers
-
Widerrufen Sie die
cluster-admin
Berechtigungen mit dem folgenden Befehl. Ersetzen Sie<IDP_USER_NAME>
und<CLUSTER_NAME>
durch Ihren Benutzer und Cluster Namen.rosa revoke user cluster-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
-
Stellen Sie sicher, dass der Benutzer nicht als Mitglied der
cluster-admins
Gruppe aufgeführt ist.rosa list users --cluster=<CLUSTER_NAME>
Widerrufen dedicated-admin
Sie die Berechtigungen eines Benutzers
-
Widerrufen Sie die
dedicated-admin
Berechtigungen mit dem folgenden Befehl. Ersetzen Sie<IDP_USER_NAME>
und<CLUSTER_NAME>
durch Ihren Benutzer und Cluster Namen.rosa revoke user dedicated-admin --user=<IDP_USER_NAME> --cluster=<CLUSTER_NAME>
-
Stellen Sie sicher, dass der Benutzer nicht als Mitglied der
dedicated-admins
Gruppe aufgeführt ist.rosa list users --cluster=<CLUSTER_NAME>
Widerrufen Sie den Benutzerzugriff auf eine Cluster
Sie können einem Identity Provider-Benutzer den Cluster Zugriff entziehen, indem Sie ihn aus dem konfigurierten Identity Provider entfernen.
Sie können verschiedene Arten von Identitätsanbietern für Ihren konfigurieren Cluster. Mit dem folgenden Verfahren wird einem Mitglied einer GitHub Organisation der Cluster Zugriff entzogen.
-
Navigieren Sie zu github.com
und melden Sie sich bei Ihrem GitHub Konto an. -
Entferne den Benutzer aus deiner GitHub Organisation. Weitere Informationen finden Sie in der GitHub Dokumentation unter Ein Mitglied aus Ihrer Organisation entfernen
.
Löschen Sie einen Cluster und AWS STS Ressourcen
Sie können den verwenden ROSA CLI, um eine zu löschen Cluster , die AWS Security Token Service (AWS STS) verwendet. Sie können den auch verwenden ROSA CLI, um die IAM Rollen und den OIDC Anbieter zu löschen, die von erstellt wurden ROSA. Um die von erstellten IAM Richtlinien zu löschen ROSA, können Sie die IAM Konsole verwenden.
Wichtig
IAM Rollen und Richtlinien, die von erstellt wurden, ROSA können von anderen ROSA Clustern im selben Konto verwendet werden.
-
Löschen Sie die Cluster und sehen Sie sich die Protokolle an.
<CLUSTER_NAME>
Ersetzen Sie durch den Namen oder die ID Ihres Cluster.rosa delete cluster --cluster=<CLUSTER_NAME> --watch
Wichtig
Sie müssen warten Cluster , bis der vollständig gelöscht ist, bevor Sie die IAM Rollen, Richtlinien und den OIDC Anbieter entfernen. Die IAM Kontorollen sind erforderlich, um die vom Installationsprogramm erstellten Ressourcen zu löschen. Die IAM Operatorrollen sind erforderlich, um die von den OpenShift Operatoren erstellten Ressourcen zu bereinigen. Die Betreiber verwenden den OIDC Anbieter zur Authentifizierung.
-
Löschen Sie den OIDC Anbieter, den die Cluster Operatoren zur Authentifizierung verwenden, indem Sie den folgenden Befehl ausführen.
rosa delete oidc-provider -c <CLUSTER_ID> --mode auto
-
Löschen Sie die clusterspezifischen Operatorrollen. IAM
rosa delete operator-roles -c <CLUSTER_ID> --mode auto
-
Löschen Sie die IAM Kontorollen mit dem folgenden Befehl.
<PREFIX>
Ersetzen Sie es durch das Präfix der zu löschenden IAM Kontorollen. Wenn Sie beim Erstellen der IAM Kontorollen ein benutzerdefiniertes Präfix angegeben haben, geben Sie dasManagedOpenShift
Standardpräfix an.rosa delete account-roles --prefix <PREFIX> --mode auto
-
Löschen Sie die IAM Richtlinien, die von erstellt wurden ROSA.
-
Melden Sie sich bei der IAM -Konsole
an. -
Wählen Sie im linken Menü unter Zugriffsverwaltung die Option Richtlinien aus.
-
Wählen Sie die Richtlinie aus, die Sie löschen möchten, und wählen Sie Aktionen > Löschen.
-
Geben Sie den Richtliniennamen ein und wählen Sie Löschen aus.
-
Wiederholen Sie diesen Schritt, um alle IAM Richtlinien für zu löschen Cluster.
-