1. AWS コンソールページで Get started ボタンをクリックして、ROSA with HCP 製品をアクティブ化します。

   

   以前に ROSA をアクティブ化したが、プロセスを完了していない場合は、ボタンをクリックして、次の手順で説明するようにアカウントのリンクを完了できます。

2. 連絡先情報を Red Hat と共有することを確認し、サービスを有効にします。

   
   • このステップでサービスを有効にしても料金は発生しません。課金と計測が連携されるのは、最初のクラスターをデプロイした後のみです。これには数分かかる場合があります。

3. プロセスが完了すると、確認メッセージが表示されます。

   

4. この検証ページの他のセクションには、追加の前提条件 (が満たされているかどうか) のステータスが表示されます。これらの前提条件のいずれかが満たされていない場合は、それぞれのメッセージが表示されます。選択したリージョンで割り当てが不十分な例を次に示します。

   
   1. Increase service quotas ボタンをクリックするか、Learn more リンクを使用して、サービスクォータの管理方法に関する詳細情報を取得します。クォータが不十分な場合、クォータはリージョン固有であることに注意してください。Web コンソールの右上隅にあるリージョンスイッチャーを使用して、関心のあるリージョンのクォータチェックを再実行し、必要に応じてサービスクォータの増加リクエストを送信できます。

5. すべての前提条件が満たされている場合、ページは次のようになります。

   

   ELB サービスにリンクされたロールは自動的に作成されます。青色の小さな Info リンクをクリックすると、状況に応じたヘルプやリソースが表示されます。

1. オレンジ色の Continue to Red Hat ボタンをクリックして、アカウントのリンクを続行します。

   

2. 現在のブラウザーのセッションで Red Hat アカウントにまだログインしていない場合は、アカウントにログインするように求められます。

   
   • このページでは、新しい Red Hat アカウントに登録したり、パスワードをリセットしたりすることもできます。
   • 前の手順で ROSA with HCP をアクティブ化した AWS アカウントに関連付ける予定の Red Hat アカウントにログインしてください。
   • Red Hat アカウントに関連付けることができるのは、サービスの請求に使用される AWS アカウント 1 つのみです。通常、個々の AWS エンドユーザーアカウントではなく、開発者アカウントなどの他の AWS アカウントがリンクされている組織の AWS アカウントが請求の対象となります。
   • 同じ Red Hat 組織に属する Red Hat アカウントは、同じ AWS アカウントにリンクされます。したがって、ROSA with HCP クラスターの作成にアクセスできるユーザーを Red Hat 組織アカウントレベルで管理できます。

3. 利用規約を確認した後、Red Hat アカウントの連携を完了させます。

   注記

   このステップは、ログインしている Red Hat アカウント、または Red Hat アカウントを管理する Red Hat 組織が以前に AWS アカウントにリンクされていない場合にのみ使用できます。

   

   Red Hat と AWS の両方のアカウント番号がこの画面に表示されます。

4. サービス規約に同意する場合は、Connect accounts ボタンをクリックします。

   Red Hat Hybrid Cloud Console を初めて使用する場合は、最初の ROSA クラスターを作成する前に、一般的なマネージドサービスの利用規約に同意するよう求められます。

   

   View Terms and Conditions ボタンをクリックすると、確認して同意する必要がある追加の規約が表示されます。

   

   この時点で追加の条件を確認し、プロンプトが表示されたら同意を確定します。

5. Hybrid Cloud Console は、AWS の前提条件に対応済みであることを認識し、クラスターデプロイメントに必要な最初の手順がリストされます。

   

6. 次の手順は、クラスターの技術的なデプロイメントに関連するものです。

   
   • これらの手順は、サービスの有効化とアカウントのリンクが完了したマシンとは別のマシンで実行される可能性があります。

   • 前述したように、Red Hat アカウントが、ROSA サービスをアクティブ化した AWS アカウントにリンクされた Red Hat 組織に属する場合は、クラスターの作成権限があり、以前に Red Hat 組織にリンクされていた請求 AWS アカウントを選択できます。

     このページの最後のセクションでは、rosa CLI または Web コンソールを使用したクラスターデプロイメントオプションを示します。

     
   • 次の手順では、rosa CLI を使用したクラスターデプロイメントについて説明します。
   • Web コンソールのみを使用したデプロイメントを行う場合は、ROSA with HCP cluster deployment using the web console セクションまでスキップできます。ただし、アカウントロールの作成など、特定のタスクには rosa CLI が必要であることに注意してください。ROSA を初めてデプロイする場合は、rosa whoami コマンドを実行するまで、この CLI の手順に従い、その後はスキップして Web コンソールのデプロイメント手順を実行してください。

1. Download the ROSA CLI ボタンをクリックして、オペレーティングシステム用の ROSA コマンドラインインターフェイス (CLI) をダウンロードし、Help with ROSA CLI setup の説明に従ってセットアップします。

   重要

   最新の AWS CLI がインストールされていることを確認してください。詳細は AWS CLI をインストールする手順 を参照してください。

2. 前の手順が完了したら、rosa version を実行して、両方の CLI が使用できることを確認できます。このコマンドは、ターミナルで古いバージョンと aws –version コマンドを使用している場合に更新通知を表示します。

3. ROSA with HCP クラスターを作成するための前提条件は、Web コンソールで rosa cli を使用して、一意のトークンで独自のコマンドを実行し、ログインしてください。この説明は、2.1To authenticate, run this command を参照してください。copy ボタンを使用すると、完全なトークンを含むコマンドを簡単にコピーしてターミナルに貼り付けることができます。

   

   独自のトークンを共有しないでください。

4. 初めてクラスターをデプロイするための最後の前提条件として、必要とされるアカウント全体のロールおよびポリシーを作成します。rosa CLI で、該当するコマンドを使用できます。方法は、2.2必要とされるアカウント全体のロールおよびポリシーを素早く作成する方法 を参照してください。これに代わる方法は、これらのロールとポリシーを手動で作成することです。

5. ログインし、アカウントロールを作成して、rosa whoami コマンドを使用し、アイデンティティーを確認します。この操作のターミナルの内容は、次のようになります。

   

6. 表示されたコマンドを使用してクラスターのデプロイメントを開始します。もう一度 copy ボタンをクリックして、ターミナルにコマンドを貼り付けます。

   
7. カスタムの AWS プロファイルを使用するには、~/.aws/credentials で指定したデフォルト以外のプロファイルのいずれかを使用します。rosa create cluster コマンドに –profile <profile_name> のセレクターを追加すると、コマンドは rosa create cluster –profile stage のようになります。このオプションを使用して、AWS CLI プロファイルが指定されていない場合は、デフォルトの AWS CLI プロファイルにより、AWS インフラストラクチャーのプロファイルがどのクラスターにデプロイされるかが決定されます。請求用 AWS プロファイルは、次のいずれかの手順で選択します。

8. クラスター名を入力すると、Hosted Control Plane を使用するかどうかを尋ねられます。YES を選択します。

   

9. ROSA with HCP クラスターをデプロイする場合、請求先の AWS アカウントを指定する必要があります。

   
   • 現在使用されている Red Hat 組織にリンクされている AWS アカウントのみが表示されます。
   • インフラストラクチャー AWS アカウントが同じ AWS 組織内でそのアカウントにリンクされているかどうかに関係なく、指定された AWS アカウントは ROSA サービスの使用に対して課金されます。
   • 特定の AWS 請求先アカウントに対して ROSA の契約が有効になっているかどうかを示すインジケーターが表示されます。
   • 契約が有効になっていない AWS アカウントを選択するには、このチュートリアルの最初のいくつかの手順を参照して契約を有効にし、クラスターデプロイメントを正常に実行するために必要なサービス課金を許可します。

10. 次の手順では、デプロイするクラスターの技術的な詳細を指定します。

    
    • これらの手順は、このチュートリアルの範囲外です。CLI を使用して ROSA with HCP クラスターのデプロイメントを完了する方法の詳細は デフォルトオプションを使用した ROSA with HCP クラスターの作成 を参照してください。

1. Web コンソールを使用してクラスターを作成するには、ROSA のセットアップ ページの下部セクションにある 2 番目のオプションを選択します。

   

2. Web コンソールを使用して ROSA クラスターを作成する場合の最初のステップは、コントロールプレーンの選択です。Next ボタンをクリックする前に、Hosted オプションが選択されていることを確認してください。

   

3. 次のステップ アカウントとロール では、ROSA クラスターがデプロイされ、リソースを消費および管理するインフラストラクチャー AWS アカウントを指定できます。

   
   • ROSA クラスターのデプロイ先のアカウントが表示されない場合は、How to associate a new AWS account をクリックして、この関連付けに関して、アカウントロールの作成またはリンクの情報を参照してください。
   • これには rosa CLI を使用します。
   • 複数の AWS アカウントを使用しており、それらのプロファイルが AWS CLI 用に設定されている場合は、rosa CLI コマンドを使用するときに --profile セレクターを使用して AWS プロファイルを指定できます。

4. 請求先の AWS アカウントは、すぐ次のセクションで選択されます。

   
   • 現在使用されている Red Hat 組織にリンクされている AWS アカウントのみが表示されます。
   • インフラストラクチャー AWS アカウントが同じ AWS 組織内でそのアカウントにリンクされているかどうかに関係なく、指定された AWS アカウントは ROSA サービスの使用に対して課金されます。
   • 特定の AWS 請求先アカウントに対して ROSA 契約が有効になっているかどうかを示すインジケーターを確認できます。
   • 契約がまだ有効になっていない AWS アカウントを使用したい場合は、Connect ROSA to a new AWS billing account を使用して ROSA AWS コンソールページにアクセスし、ログイン後に有効化できます。先ほど、このチュートリアルで説明した手順に従って、それぞれの AWS アカウントを作成するか、AWS アカウントの管理者に依頼してください。

1. スクリプトを使用するには、bash ターミナルで次のコマンドを実行します (-p オプションはロールの接頭辞を定義します)。

   $ mkdir scratch
   $ cd scratch
   $ cat << 'EOF' > verify-permissions.sh
   #!/bin/bash
   while getopts 'p:' OPTION; do
     case "$OPTION" in
       p)
         PREFIX="$OPTARG"
         ;;
       ?)
         echo "script usage: $(basename \$0) [-p PREFIX]" >&2
         exit 1
         ;;
     esac
   done
   shift "$(($OPTIND -1))"
   rosa create account-roles --mode manual --prefix $PREFIX
   INSTALLER_POLICY=$(cat sts_installer_permission_policy.json | jq )
   CONTROL_PLANE_POLICY=$(cat sts_instance_controlplane_permission_policy.json | jq)
   WORKER_POLICY=$(cat sts_instance_worker_permission_policy.json | jq)
   SUPPORT_POLICY=$(cat sts_support_permission_policy.json | jq)
   simulatePolicy () {
       outputFile="${2}.results"
       echo $2
       aws iam simulate-custom-policy --policy-input-list "$1" --action-names $(jq '.Statement | map(select(.Effect == "Allow"))[].Action | if type == "string" then . else .[] end' "$2" -r) --output text > $outputFile
   }
   simulatePolicy "$INSTALLER_POLICY" "sts_installer_permission_policy.json"
   simulatePolicy "$CONTROL_PLANE_POLICY" "sts_instance_controlplane_permission_policy.json"
   simulatePolicy "$WORKER_POLICY" "sts_instance_worker_permission_policy.json"
   simulatePolicy "$SUPPORT_POLICY" "sts_support_permission_policy.json"
   EOF
   $ chmod +x verify-permissions.sh
   $ ./verify-permissions.sh -p SimPolTest

2. スクリプトが完了したら、各結果ファイルを確認して、必要な API 呼び出しがブロックされていないことを確認します。

   $ for file in $(ls *.results); do echo $file; cat $file; done

   出力は以下のようになります。

   sts_installer_permission_policy.json.results
   EVALUATIONRESULTS       autoscaling:DescribeAutoScalingGroups   allowed *
   MATCHEDSTATEMENTS       PolicyInputList.1       IAM Policy
   ENDPOSITION     6       195
   STARTPOSITION   17      3
   EVALUATIONRESULTS       ec2:AllocateAddress     allowed *
   MATCHEDSTATEMENTS       PolicyInputList.1       IAM Policy
   ENDPOSITION     6       195
   STARTPOSITION   17      3
   EVALUATIONRESULTS       ec2:AssociateAddress    allowed *
   MATCHEDSTATEMENTS       PolicyInputList.1       IAM Policy
   ...

   注記

   アクションがブロックされている場合は、AWS が提供するエラーを確認し、管理者に相談して、SCP によって必要な API 呼び出しがブロックされているかどうかを判断してください。

1. 次の環境変数を設定し、お使いのクラスターに合わせてクラスター名を変更します。

   注記

   管理者としてログインしている必要があります。

   $ export ROSA_CLUSTER_NAME=$(oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"  | sed 's/-[a-z0-9]\{5\}$//')
   $ export REGION=$(rosa describe cluster -c ${ROSA_CLUSTER_NAME} --output json | jq -r .region.id)
   $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o json | jq -r .spec.serviceAccountIssuer | sed  's|^https://||')
   $ export AWS_ACCOUNT_ID=`aws sts get-caller-identity --query Account --output text`
   $ export AWS_PAGER=""
   $ export SCRATCH="/tmp/${ROSA_CLUSTER_NAME}/clf-cloudwatch-sts"
   $ mkdir -p ${SCRATCH}

2. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "Cluster: ${ROSA_CLUSTER_NAME}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"

1. ロギング用の Identity Access Management (IAM) ポリシーを作成します。

   $ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaCloudWatch'].{ARN:Arn}" --output text)
   $ if [[ -z "${POLICY_ARN}" ]]; then
   cat << EOF > ${SCRATCH}/policy.json
   {
     "Version": "2012-10-17",
     "Statement": [
        {
              "Effect": "Allow",
              "Action": [
                 "logs:CreateLogGroup",
                 "logs:CreateLogStream",
                 "logs:DescribeLogGroups",
                 "logs:DescribeLogStreams",
                 "logs:PutLogEvents",
                 "logs:PutRetentionPolicy"
              ],
              "Resource": "arn:aws:logs:*:*:*"
        }
   ]
   }
   EOF
   POLICY_ARN=$(aws iam create-policy --policy-name "RosaCloudWatch" \
   --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn --output text)
   fi
   $ echo ${POLICY_ARN}

2. クラスターの IAM ロール信頼ポリシーを作成します。

   $ cat <<EOF > ${SCRATCH}/trust-policy.json
   {
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Principal": {
          "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}"
        },
        "Action": "sts:AssumeRoleWithWebIdentity",
        "Condition": {
          "StringEquals": {
            "${OIDC_ENDPOINT}:sub": "system:serviceaccount:openshift-logging:logcollector"
          }
        }
      }]
   }
   EOF
   $ ROLE_ARN=$(aws iam create-role --role-name "${ROSA_CLUSTER_NAME}-RosaCloudWatch" \
         --assume-role-policy-document file://${SCRATCH}/trust-policy.json \
         --query Role.Arn --output text)
   $ echo ${ROLE_ARN}

3. IAM ポリシーを IAM ロールに割り当てます。

   $ aws iam attach-role-policy --role-name "${ROSA_CLUSTER_NAME}-RosaCloudWatch" \
      --policy-arn ${POLICY_ARN}

1. Red Hat OpenShift Logging Operator をデプロイします。

   $  cat << EOF | oc apply -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        labels:
         operators.coreos.com/cluster-logging.openshift-logging: ""
        name: cluster-logging
        namespace: openshift-logging
      spec:
        channel: stable
        installPlanApproval: Automatic
        name: cluster-logging
        source: redhat-operators
        sourceNamespace: openshift-marketplace
   EOF

2. シークレットを作成します。

   $  cat << EOF | oc apply -f -
     apiVersion: v1
     kind: Secret
     metadata:
       name: cloudwatch-credentials
       namespace: openshift-logging
     stringData:
       role_arn: $ROLE_ARN
   EOF

1. ClusterLogForwarder カスタムリソース (CR) を作成します。

   $ cat << EOF | oc apply -f -
     apiVersion: "logging.openshift.io/v1"
     kind: ClusterLogForwarder
     metadata:
       name: instance
       namespace: openshift-logging
     spec:
       outputs:
         - name: cw
           type: cloudwatch
           cloudwatch:
             groupBy: namespaceName
             groupPrefix: rosa-${ROSA_CLUSTER_NAME}
             region: ${REGION}
           secret:
             name: cloudwatch-credentials
       pipelines:
         - name: to-cloudwatch
           inputRefs:
             - infrastructure
             - audit
             - application
           outputRefs:
             - cw
   EOF

2. ClusterLogging CR を作成します。

   $ cat << EOF | oc apply -f -
     apiVersion: logging.openshift.io/v1
     kind: ClusterLogging
     metadata:
       name: instance
       namespace: openshift-logging
     spec:
       collection:
         logs:
            type: vector
       managementState: Managed
   EOF

1. ClusterLogForwarder CR を削除します。

   $ oc delete -n openshift-logging clusterlogforwarder instance

2. ClusterLogging CR を削除します。

   $ oc delete -n openshift-logging clusterlogging instance

3. IAM ロールから IAM ポリシーの割り当てを解除します。

   $ aws iam detach-role-policy --role-name "${ROSA_CLUSTER_NAME}-RosaCloudWatch" \
      --policy-arn "${POLICY_ARN}"

4. IAM ロールを削除します。

   $ aws iam delete-role --role-name "${ROSA_CLUSTER_NAME}-RosaCloudWatch"

5. IAM ポリシーを削除します。

   重要

   IAM ポリシーは、そのポリシーを使用している他のリソースがない場合にのみ削除してください。

   $ aws iam delete-policy --policy-arn "${POLICY_ARN}"

6. CloudWatch ロググループを削除します。

   $ aws logs delete-log-group --log-group-name "rosa-${ROSA_CLUSTER_NAME}.audit"
   $ aws logs delete-log-group --log-group-name "rosa-${ROSA_CLUSTER_NAME}.infrastructure"

手順

1. 新しいプロジェクトを作成する

   $ oc new-project waf-demo

2. 秘密鍵と公開証明書から新しい TLS シークレットを作成します。fullchain.pem は完全なワイルドカード証明書チェーン (中間証明書を含む)、privkey.pem はワイルドカード証明書の秘密鍵です。

   例

   $ oc -n waf-demo create secret tls waf-tls --cert=fullchain.pem --key=privkey.pem

3. 新規の CustomDomain カスタムリソース (CR) を作成します。

   waf-custom-domain.yaml の例

   apiVersion: managed.openshift.io/v1alpha1
   kind: CustomDomain
   metadata:
     name: cloudfront-waf
   spec:
     domain: apps.<company_name>.io 1
     scope: External
     loadBalancerType: NLB
     certificate:
       name: waf-tls
       namespace: waf-demo
     routeSelector: 2
       matchLabels:
        route: waf

   1

   カスタムドメイン。

   2

   CustomDomain ingress によって提供されるルートのセットをフィルターします。このチュートリアルでは waf ルートセレクターを使用しますが、値を指定しないと、フィルター処理は行われません。

4. CR を適用します。

   例

   $ oc apply -f waf-custom-domain.yaml

5. カスタムドメイン Ingress Controller がデプロイされ、Ready ステータスになっていることを確認します。

   $ oc get customdomains

   出力例

   NAME               ENDPOINT                                                    DOMAIN                       STATUS
   cloudfront-waf     xxrywp.<company_name>.cluster-01.opln.s1.openshiftapps.com  *.apps.<company_name>.io     Ready

1. 新しく作成したカスタムドメイン Ingress Controller の NLB ホスト名を取得します。

   $ NLB=$(oc -n openshift-ingress get service router-cloudfront-waf \
     -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
   $ echo "Origin domain: ${NLB}"

2. 証明書を Amazon Certificate Manager にインポートします。cert.pem はワイルドカード証明書、fullchain.pem はワイルドカード証明書のチェーン、privkey.pem はワイルドカード証明書の秘密鍵です。

   注記

   この証明書は、クラスターがデプロイされているリージョンに関係なく us-east-1 にインポートする必要があります。Amazon CloudFront はグローバル AWS サービスであるためです。

   例

   $ aws acm import-certificate --certificate file://cert.pem \
     --certificate-chain file://fullchain.pem \
     --private-key file://privkey.pem \
     --region us-east-1

3. AWS コンソール にログインして、CloudFront ディストリビューションを作成します。

4. 次の情報を使用して、CloudFront ディストリビューションを設定します。

   注記

   以下の表でオプションが指定されていない場合は、デフォルトのままにしておきます (空白でも構いません)。

   オプション	値
   Origin domain	上記のコマンドの出力 [1]
   Name	rosa-waf-ingress [2]
   Viewer protocol policy	Redirect HTTP to HTTPS
   Allowed HTTP methods	GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
   Cache policy	CachingDisabled
   Origin request policy	AllViewer
   Web Application Firewall (WAF)	Enable security protections
   Use existing WAF configuration	true
   Choose a web ACL	cloudfront-waf
   Alternate domain name (CNAME)	*.apps.<company_name>.io [3]
   Custom SSL certificate	上のステップでインポートした証明書を選択 [4]

   1. origin domain を取得するには、echo ${NLB} を実行します。
   2. 複数のクラスターがある場合は、オリジンの名前が一意であることを確認してください。
   3. これは、カスタムドメイン Ingress Controller の作成に使用したワイルドカードドメインと同じである必要があります。
   4. これは、上で入力した alternate domain name と同じである必要があります。

5. Amazon CloudFront ディストリビューションエンドポイントを取得します。

   $ aws cloudfront list-distributions --query "DistributionList.Items[?Origins.Items[?DomainName=='${NLB}']].DomainName" --output text

6. CNAME を持つカスタムのワイルドカードドメインの DNS を、前述のステップの Amazon CloudFront ディストリビューションエンドポイントに更新します。

   例

   *.apps.<company_name>.io CNAME d1b2c3d4e5f6g7.cloudfront.net

1. Hello World アプリケーションをデプロイします。

   $ oc -n waf-demo new-app --image=docker.io/openshift/hello-openshift

2. カスタムドメイン名を指定してアプリケーションのルートを作成します。

   例

   $ oc -n waf-demo create route edge --service=hello-openshift hello-openshift-tls \
   --hostname hello-openshift.apps.<company_name>.io

3. ルートにラベルを付けて、カスタムドメイン Ingress Controller へのアクセスを許可します。

   $ oc -n waf-demo label route.route.openshift.io/hello-openshift-tls route=waf

1. アプリが Amazon CloudFront の背後でアクセスできることをテストします。

   例

   $ curl "https://hello-openshift.apps.<company_name>.io"

   出力例

   Hello OpenShift!

2. WAF が不正な要求を拒否することをテストします。

   例

   $ curl -X POST "https://hello-openshift.apps.<company_name>.io" \
     -F "user='<script><alert>Hello></alert></script>'"

   出力例

   <html>
   <head><title>403 Forbidden</title></head>
   <body>
   <center><h1>403 Forbidden</h1></center>
   </body>
   </html

   予期される結果は 403 Forbidden エラーです。このエラーが返されれば、アプリケーションは AWS WAF によって保護されています。

1. AWS Load Balancer Controller の AWS IAM ポリシーを作成します。

   注記

   このポリシーは、アップストリームの AWS Load Balancer Controller ポリシー に加えて、サブネット上にタグを作成する権限から取得されます。これは Operator が機能するために必要です。

   $ oc new-project aws-load-balancer-operator
   $ POLICY_ARN=$(aws iam list-policies --query \
        "Policies[?PolicyName=='aws-load-balancer-operator-policy'].{ARN:Arn}" \
        --output text)
   $ if [[ -z "${POLICY_ARN}" ]]; then
       wget -O "${SCRATCH}/load-balancer-operator-policy.json" \
          https://raw.githubusercontent.com/rh-mobb/documentation/main/content/rosa/aws-load-balancer-operator/load-balancer-operator-policy.json
        POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn \
        --output text iam create-policy \
        --policy-name aws-load-balancer-operator-policy \
        --policy-document "file://${SCRATCH}/load-balancer-operator-policy.json")
   fi
   $ echo $POLICY_ARN

2. AWS Load Balancer Operator の AWS IAM 信頼ポリシーを作成します。

   $ cat <<EOF > "${SCRATCH}/trust-policy.json"
   {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Condition": {
      "StringEquals" : {
        "${OIDC_ENDPOINT}:sub": ["system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager", "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"]
      }
    },
    "Principal": {
      "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity"
    }
    ]
   }
   EOF

3. AWS Load Balancer Operator の AWS IAM ロールを作成します。

   $ ROLE_ARN=$(aws iam create-role --role-name "${CLUSTER_NAME}-alb-operator" \
      --assume-role-policy-document "file://${SCRATCH}/trust-policy.json" \
      --query Role.Arn --output text)
   $ echo $ROLE_ARN
   
   $ aws iam attach-role-policy --role-name "${CLUSTER_NAME}-alb-operator" \
        --policy-arn $POLICY_ARN

4. 新しく作成した AWS IAM ロールを引き受けるための AWS Load Balancer Operator 用のシークレットを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   stringData:
     credentials: |
       [default]
       role_arn = $ROLE_ARN
       web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
   EOF

5. Red Hat AWS Load Balancer Operator をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     upgradeStrategy: Default
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     channel: stable-v1.0
     installPlanApproval: Automatic
     name: aws-load-balancer-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: aws-load-balancer-operator.v1.0.0
   EOF

6. 次の Operator を使用して、AWS Load Balancer Controller のインスタンスをデプロイします。

   注記

   ここでエラーが発生した場合は、少し待ってから再試行してください。エラーが発生するのは、Operator がまだインストールを完了していないためです。

   $ cat << EOF | oc apply -f -
   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController
   metadata:
     name: cluster
   spec:
     credentials:
       name: aws-load-balancer-operator
     enabledAddons:
       - AWSWAFv2
   EOF

7. Operator Pod とコントローラー Pod の両方が実行されていることを確認します。

   $ oc -n aws-load-balancer-operator get pods

   次のようなメッセージが表示されます。表示されない場合は、少し待ってから再試行してください。

   NAME                                                             READY   STATUS    RESTARTS   AGE
   aws-load-balancer-controller-cluster-6ddf658785-pdp5d            1/1     Running   0          99s
   aws-load-balancer-operator-controller-manager-577d9ffcb9-w6zqn   2/2     Running   0          2m4s

1. サンプルアプリケーション用に新しいプロジェクトを作成します。

   $ oc new-project hello-world

2. Hello World アプリケーションをデプロイします。

   $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift

3. 事前に作成済みのサービスリソースを NodePort サービスタイプに変換します。

   $ oc -n hello-world patch service hello-openshift -p '{"spec":{"type":"NodePort"}}'

4. AWS Load Balancer Operator を使用して AWS ALB をデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: hello-openshift-alb
     namespace: hello-world
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
   spec:
     ingressClassName: alb
     rules:
       - http:
           paths:
             - path: /
               pathType: Exact
               backend:
                 service:
                   name: hello-openshift
                   port:
                     number: 8080
   EOF

5. AWS ALB Ingress エンドポイントを curl して、Hello World アプリケーションにアクセスできることを確認します。

   注記

   AWS ALB のプロビジョニングには数分かかります。curl: (6) Could not resolve host というエラーが表示された場合は、待機してから再試行してください。

   $ INGRESS=$(oc -n hello-world get ingress hello-openshift-alb -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
   $ curl "http://${INGRESS}"

   出力例

   Hello OpenShift!

1. S3 アクセスを許可する IAM ポリシーを作成します。

   $ POLICY_ARN=$(aws iam list-policies --query "Policies[?PolicyName=='RosaOadpVer1'].{ARN:Arn}" --output text)
   if [[ -z "${POLICY_ARN}" ]]; then
   $ cat << EOF > ${SCRATCH}/policy.json
   {
   "Version": "2012-10-17",
   "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:CreateBucket",
        "s3:DeleteBucket",
        "s3:PutBucketTagging",
        "s3:GetBucketTagging",
        "s3:PutEncryptionConfiguration",
        "s3:GetEncryptionConfiguration",
        "s3:PutLifecycleConfiguration",
        "s3:GetLifecycleConfiguration",
        "s3:GetBucketLocation",
        "s3:ListBucket",
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucketMultipartUploads",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts",
        "ec2:DescribeSnapshots",
        "ec2:DescribeVolumes",
        "ec2:DescribeVolumeAttribute",
        "ec2:DescribeVolumesModifications",
        "ec2:DescribeVolumeStatus",
        "ec2:CreateTags",
        "ec2:CreateVolume",
        "ec2:CreateSnapshot",
        "ec2:DeleteSnapshot"
      ],
      "Resource": "*"
    }
   ]}
   EOF
   $ POLICY_ARN=$(aws iam create-policy --policy-name "RosaOadpVer1" \
   --policy-document file:///${SCRATCH}/policy.json --query Policy.Arn \
   --tags Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-oadp Key=operator_name,Value=openshift-oadp \
   --output text)
   fi
   $ echo ${POLICY_ARN}

2. クラスターの IAM ロール信頼ポリシーを作成します。

   $ cat <<EOF > ${SCRATCH}/trust-policy.json
   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Principal": {
         "Federated": "arn:aws:iam::${AWS_ACCOUNT_ID}:oidc-provider/${OIDC_ENDPOINT}"
       },
       "Action": "sts:AssumeRoleWithWebIdentity",
       "Condition": {
         "StringEquals": {
            "${OIDC_ENDPOINT}:sub": [
              "system:serviceaccount:openshift-adp:openshift-adp-controller-manager",
              "system:serviceaccount:openshift-adp:velero"]
         }
       }
     }]
   }
   EOF
   $ ROLE_ARN=$(aws iam create-role --role-name \
    "${ROLE_NAME}" \
     --assume-role-policy-document file://${SCRATCH}/trust-policy.json \
     --tags Key=rosa_cluster_id,Value=${ROSA_CLUSTER_ID} Key=rosa_openshift_version,Value=${CLUSTER_VERSION} Key=rosa_role_prefix,Value=ManagedOpenShift Key=operator_namespace,Value=openshift-adp Key=operator_name,Value=openshift-oadp \
     --query Role.Arn --output text)
   
   $ echo ${ROLE_ARN}

3. IAM ポリシーを IAM ロールに割り当てます。

   $ aws iam attach-role-policy --role-name "${ROLE_NAME}" \
    --policy-arn ${POLICY_ARN}

1. OADP の namespace を作成します。

   $ oc create namespace openshift-adp

2. 認証情報のシークレットを作成します。

   $ cat <<EOF > ${SCRATCH}/credentials
   [default]
   role_arn = ${ROLE_ARN}
   web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
   EOF
   $ oc -n openshift-adp create secret generic cloud-credentials \
    --from-file=${SCRATCH}/credentials

3. OADP Operator をデプロイします。

   注記

   現在、Operator のバージョン 1.1 では、バックアップが PartiallyFailed ステータスになるという問題があります。これはバックアップと復元のプロセスには影響しないと思われますが、それに関連する問題があるため注意が必要です。

   $ cat << EOF | oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
    generateName: openshift-adp-
    namespace: openshift-adp
    name: oadp
   spec:
    targetNamespaces:
    - openshift-adp
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
    name: redhat-oadp-operator
    namespace: openshift-adp
   spec:
    channel: stable-1.2
    installPlanApproval: Automatic
    name: redhat-oadp-operator
    source: redhat-operators
    sourceNamespace: openshift-marketplace
   EOF

4. Operator の準備が整うまで待ちます。

   $ watch oc -n openshift-adp get pods

   出力例

   NAME                                                READY   STATUS    RESTARTS   AGE
   openshift-adp-controller-manager-546684844f-qqjhn   1/1     Running   0          22s

5. クラウドストレージを作成します。

   $ cat << EOF | oc create -f -
   apiVersion: oadp.openshift.io/v1alpha1
   kind: CloudStorage
   metadata:
    name: ${CLUSTER_NAME}-oadp
    namespace: openshift-adp
   spec:
    creationSecret:
      key: credentials
      name: cloud-credentials
    enableSharedConfig: true
    name: ${CLUSTER_NAME}-oadp
    provider: aws
    region: $REGION
   EOF

6. アプリケーションのストレージのデフォルトのストレージクラスを確認します。

   $ oc get pvc -n <namespace> 1

   1

   アプリケーションの namespace を入力します。

   出力例

   NAME     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   applog   Bound    pvc-351791ae-b6ab-4e8b-88a4-30f73caf5ef8   1Gi        RWO            gp3-csi        4d19h
   mysql    Bound    pvc-16b8e009-a20a-4379-accc-bc81fedd0621   1Gi        RWO            gp3-csi        4d19h

   $ oc get storageclass

   出力例

   NAME                PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
   gp2                 kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   true                   4d21h
   gp2-csi             ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
   gp3                 ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h
   gp3-csi (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   4d21h

   gp3-csi、gp2-csi、gp3、または gp2 のいずれかを使用すると機能します。バックアップ対象のアプリケーションがすべて CSI を使用した PV を使用している場合は、OADP の DPA 設定に CSI プラグインを含めます。

7. CSI のみ: Data Protection Application をデプロイします。

   $ cat << EOF | oc create -f -
   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
    name: ${CLUSTER_NAME}-dpa
    namespace: openshift-adp
   spec:
    backupImages: true
    features:
      dataMover:
        enable: false
    backupLocations:
    - bucket:
        cloudStorageRef:
          name: ${CLUSTER_NAME}-oadp
        credential:
          key: credentials
          name: cloud-credentials
        prefix: velero
        default: true
        config:
          region: ${REGION}
    configuration:
      velero:
        defaultPlugins:
        - openshift
        - aws
        - csi
      restic:
        enable: false
   EOF

   注記

   CSI ボリュームに対してこのコマンドを実行する場合は、次のステップをスキップできます。

8. 非 CSI ボリューム: Data Protection Application をデプロイします。

   $ cat << EOF | oc create -f -
   apiVersion: oadp.openshift.io/v1alpha1
   kind: DataProtectionApplication
   metadata:
    name: ${CLUSTER_NAME}-dpa
    namespace: openshift-adp
   spec:
    backupImages: true
    features:
      dataMover:
        enable: false
    backupLocations:
    - bucket:
        cloudStorageRef:
          name: ${CLUSTER_NAME}-oadp
        credential:
          key: credentials
          name: cloud-credentials
        prefix: velero
        default: true
        config:
          region: ${REGION}
    configuration:
      velero:
        defaultPlugins:
        - openshift
        - aws
      restic:
        enable: false
    snapshotLocations:
      - velero:
          config:
            credentialsFile: /tmp/credentials/openshift-adp/cloud-credentials-credentials
            enableSharedConfig: 'true'
            profile: default
            region: ${REGION}
          provider: aws
   EOF

1. バックアップするワークロードを作成します。

   $ oc create namespace hello-world
   $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift

2. ルートを公開します。

   $ oc expose service/hello-openshift -n hello-world

3. アプリケーションが動作していることを確認します。

   $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

   出力例

   Hello OpenShift!

4. ワークロードをバックアップします。

   $ cat << EOF | oc create -f -
   apiVersion: velero.io/v1
   kind: Backup
   metadata:
    name: hello-world
    namespace: openshift-adp
   spec:
    includedNamespaces:
    - hello-world
    storageLocation: ${CLUSTER_NAME}-dpa-1
    ttl: 720h0m0s
   EOF

5. バックアップが完了するまで待ちます。

   $ watch "oc -n openshift-adp get backup hello-world -o json | jq .status"

   出力例

   {
    "completionTimestamp": "2022-09-07T22:20:44Z",
    "expiration": "2022-10-07T22:20:22Z",
    "formatVersion": "1.1.0",
    "phase": "Completed",
    "progress": {
      "itemsBackedUp": 58,
      "totalItems": 58
    },
    "startTimestamp": "2022-09-07T22:20:22Z",
    "version": 1
   }

6. デモワークロードを削除します。

   $ oc delete ns hello-world

7. バックアップから復元します。

   $ cat << EOF | oc create -f -
   apiVersion: velero.io/v1
   kind: Restore
   metadata:
    name: hello-world
    namespace: openshift-adp
   spec:
    backupName: hello-world
   EOF

8. 復元が完了するまで待ちます。

   $ watch "oc -n openshift-adp get restore hello-world -o json | jq .status"

   出力例

   {
    "completionTimestamp": "2022-09-07T22:25:47Z",
    "phase": "Completed",
    "progress": {
      "itemsRestored": 38,
      "totalItems": 38
    },
    "startTimestamp": "2022-09-07T22:25:28Z",
    "warnings": 9
   }

9. ワークロードが復元されていることを確認します。

   $ oc -n hello-world get pods

   出力例

   NAME                              READY   STATUS    RESTARTS   AGE
   hello-openshift-9f885f7c6-kdjpj   1/1     Running   0          90s

   $ curl `oc get route/hello-openshift -n hello-world -o jsonpath='{.spec.host}'`

   出力例

   Hello OpenShift!

10. トラブルシューティングのヒントについては、OADP チームの トラブルシューティングドキュメント を参照してください。
11. 追加のサンプルアプリケーションは、OADP チームの サンプルアプリケーションディレクトリー にあります。

1. ワークロードを削除します。

   $ oc delete ns hello-world

2. バックアップおよび復元リソースが不要になった場合は、クラスターからリソースを削除します。

   $ oc delete backup hello-world
   $ oc delete restore hello-world

3. s3 のバックアップ/復元オブジェクトとリモートオブジェクトを削除するには、以下を実行します。

   $ velero backup delete hello-world
   $ velero restore delete hello-world

4. Data Protection Application を削除します。

   $ oc -n openshift-adp delete dpa ${CLUSTER_NAME}-dpa

5. クラウドストレージを削除します。

   $ oc -n openshift-adp delete cloudstorage ${CLUSTER_NAME}-oadp

   警告

   このコマンドがハングした場合は、ファイナライザーの削除が必要になる場合があります。

   $ oc -n openshift-adp patch cloudstorage ${CLUSTER_NAME}-oadp -p '{"metadata":{"finalizers":null}}' --type=merge

6. Operator が不要になった場合は、Operator を削除します。

   $ oc -n openshift-adp delete subscription oadp-operator

7. Operator の namespace を削除します。

   $ oc delete ns redhat-openshift-adp

8. カスタムリソース定義が不要になった場合は、クラスターからカスタムリソース定義を削除します。

   $ for CRD in `oc get crds | grep velero | awk '{print $1}'`; do oc delete crd $CRD; done
   $ for CRD in `oc get crds | grep -i oadp | awk '{print $1}'`; do oc delete crd $CRD; done

9. AWS S3 バケットを削除します。

   $ aws s3 rm s3://${CLUSTER_NAME}-oadp --recursive
   $ aws s3api delete-bucket --bucket ${CLUSTER_NAME}-oadp

10. ロールからポリシーの割り当てを解除します。

    $ aws iam detach-role-policy --role-name "${ROLE_NAME}" \
     --policy-arn "${POLICY_ARN}"

11. ロールを削除します。

    $ aws iam delete-role --role-name "${ROLE_NAME}"

1. AWS Load Balancer Controller の AWS IAM ポリシーを作成します。

   注記

   このポリシーは、アップストリームの AWS Load Balancer Controller ポリシー に加えて、サブネット上にタグを作成する権限から取得されます。これは Operator が機能するために必要です。

   $ oc new-project aws-load-balancer-operator
   $ POLICY_ARN=$(aws iam list-policies --query \
        "Policies[?PolicyName=='aws-load-balancer-operator-policy'].{ARN:Arn}" \
        --output text)
   $ if [[ -z "${POLICY_ARN}" ]]; then
       wget -O "${SCRATCH}/load-balancer-operator-policy.json" \
          https://raw.githubusercontent.com/rh-mobb/documentation/main/content/rosa/aws-load-balancer-operator/load-balancer-operator-policy.json
        POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn \
        --output text iam create-policy \
        --policy-name aws-load-balancer-operator-policy \
        --policy-document "file://${SCRATCH}/load-balancer-operator-policy.json")
   fi
   $ echo $POLICY_ARN

2. AWS Load Balancer Operator の AWS IAM 信頼ポリシーを作成します。

   $ cat <<EOF > "${SCRATCH}/trust-policy.json"
   {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Condition": {
      "StringEquals" : {
        "${OIDC_ENDPOINT}:sub": ["system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-operator-controller-manager", "system:serviceaccount:aws-load-balancer-operator:aws-load-balancer-controller-cluster"]
      }
    },
    "Principal": {
      "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity"
    }
    ]
   }
   EOF

3. AWS Load Balancer Operator の AWS IAM ロールを作成します。

   $ ROLE_ARN=$(aws iam create-role --role-name "${ROSA_CLUSTER_NAME}-alb-operator" \
      --assume-role-policy-document "file://${SCRATCH}/trust-policy.json" \
      --query Role.Arn --output text)
   $ echo $ROLE_ARN
   
   $ aws iam attach-role-policy --role-name "${ROSA_CLUSTER_NAME}-alb-operator" \
        --policy-arn $POLICY_ARN

4. 新しく作成した AWS IAM ロールを引き受けるための AWS Load Balancer Operator 用のシークレットを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Secret
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   stringData:
     credentials: |
       [default]
       role_arn = $ROLE_ARN
       web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
   EOF

5. Red Hat AWS Load Balancer Operator をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     upgradeStrategy: Default
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: aws-load-balancer-operator
     namespace: aws-load-balancer-operator
   spec:
     channel: stable-v1.0
     installPlanApproval: Automatic
     name: aws-load-balancer-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: aws-load-balancer-operator.v1.0.0
   EOF

6. 次の Operator を使用して、AWS Load Balancer Controller のインスタンスをデプロイします。

   注記

   ここでエラーが発生した場合は、少し待ってから再試行してください。エラーが発生するのは、Operator がまだインストールを完了していないためです。

   $ cat << EOF | oc apply -f -
   apiVersion: networking.olm.openshift.io/v1
   kind: AWSLoadBalancerController
   metadata:
     name: cluster
   spec:
     credentials:
       name: aws-load-balancer-operator
   EOF

7. Operator Pod とコントローラー Pod の両方が実行されていることを確認します。

   $ oc -n aws-load-balancer-operator get pods

   次のようなメッセージが表示されます。表示されない場合は、少し待ってから再試行してください。

   NAME                                                             READY   STATUS    RESTARTS   AGE
   aws-load-balancer-controller-cluster-6ddf658785-pdp5d            1/1     Running   0          99s
   aws-load-balancer-operator-controller-manager-577d9ffcb9-w6zqn   2/2     Running   0          2m4s

1. 新しいプロジェクトを作成します。

   $ oc new-project hello-world

2. Hello World アプリケーションをデプロイします。

   $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift

3. AWS ALB が接続する NodePort サービスを設定します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Service
   metadata:
     name: hello-openshift-nodeport
     namespace: hello-world
   spec:
     ports:
       - port: 80
         targetPort: 8080
         protocol: TCP
     type: NodePort
     selector:
       deployment: hello-openshift
   EOF

4. AWS Load Balancer Operator を使用して AWS ALB をデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: hello-openshift-alb
     namespace: hello-world
     annotations:
       alb.ingress.kubernetes.io/scheme: internet-facing
   spec:
     ingressClassName: alb
     rules:
       - http:
           paths:
             - path: /
               pathType: Exact
               backend:
                 service:
                   name: hello-openshift-nodeport
                   port:
                     number: 80
   EOF

5. AWS ALB Ingress エンドポイントを curl して、Hello World アプリケーションにアクセスできることを確認します。

   注記

   AWS ALB のプロビジョニングには数分かかります。curl: (6) Could not resolve host というエラーが表示された場合は、待機してから再試行してください。

   $ INGRESS=$(oc -n hello-world get ingress hello-openshift-alb \
       -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
   $ curl "http://${INGRESS}"

   出力例

   Hello OpenShift!

6. Hello World アプリケーション用に AWS NLB をデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Service
   metadata:
     name: hello-openshift-nlb
     namespace: hello-world
     annotations:
       service.beta.kubernetes.io/aws-load-balancer-type: external
       service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: instance
       service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
   spec:
     ports:
       - port: 80
         targetPort: 8080
         protocol: TCP
     type: LoadBalancer
     selector:
       deployment: hello-openshift
   EOF

7. AWS NLB エンドポイントをテストします。

   注記

   NLB のプロビジョニングには数分かかります。curl: (6) Could not resolve host というエラーが表示された場合は、待機してから再試行してください。

   $ NLB=$(oc -n hello-world get service hello-openshift-nlb \
     -o jsonpath='{.status.loadBalancer.ingress[0].hostname}')
   $ curl "http://${NLB}"

   出力例

   Hello OpenShift!

1. hello world アプリケーションの namespace (および namespace 内のすべてのリソース) を削除します。

   $ oc delete project hello-world

2. AWS Load Balancer Operator と AWS IAM ロールを削除します。

   $ oc delete subscription aws-load-balancer-operator -n aws-load-balancer-operator
   $ aws iam detach-role-policy \
     --role-name "${ROSA_CLUSTER_NAME}-alb-operator" \
     --policy-arn $POLICY_ARN
   $ aws iam delete-role \
     --role-name "${ROSA_CLUSTER_NAME}-alb-operator"

3. AWS IAM ポリシーを削除します。

   $ aws iam delete-policy --policy-arn $POLICY_ARN

手順

1. 指定の変数を変更し、次のコマンドを実行して、クラスターの OAuth コールバック URL を作成します。

   注記

   このコールバック URL を忘れずに保存してください。後のプロセスで必要になります。

   $ domain=$(rosa describe cluster -c <cluster_name> | grep "DNS" | grep -oE '\S+.openshiftapps.com')
   $ echo "OAuth callback URL: https://oauth-openshift.apps.$domain/oauth2callback/AAD"

   OAuth コールバック URL の末尾にある "AAD" ディレクトリーは、このプロセスで後で設定する OAuth アイデンティティープロバイダー名と同じである必要があります。

2. Azure portal にログインして Entra ID アプリケーションを作成し、App registrations ブレード を選択します。次に、New registration を選択して新しいアプリケーションを作成します。

   

3. アプリケーションに名前を付けます (例: openshift-auth)。
4. Redirect URI ドロップダウンから Web を選択し、前のステップで取得した OAuth コールバック URL の値を入力します。

5. 必要な情報を入力したら、Register をクリックしてアプリケーションを作成します。

   

6. Certificates & secrets サブブレードを選択し、New client secret を選択します。

   

7. 要求された詳細を入力し、生成されたクライアントシークレット値を保存します。このシークレットは、このプロセスで後で必要になります。

   重要

   初期セットアップ後は、クライアントシークレットを確認できません。クライアントシークレットを保存しなかった場合は、新しいクライアントシークレットを生成する必要があります。

   

8. Overview サブブレードを選択し、Application (client) ID と Directory (tenant) ID をメモします。これらの値は後のステップで必要になります。

   

1. Token configuration サブブレードをクリックし、Add optional claim ボタンを選択します。

   

2. ID ラジオボタンを選択します。

   

3. email クレームのチェックボックスを選択します。

   

4. preferred_username クレームのチェックボックスを選択します。次に、Add をクリックし、Entra ID アプリケーションの email および preferred_username クレームを設定します。

   

5. ページの上部にダイアログボックスが表示されます。プロンプトに従って、必要な Microsoft Graph 権限を有効にします。

   

手順

1. Token configuration サブブレードで、Add groups claim をクリックします。

   

2. Entra ID アプリケーションのグループクレームを設定するには、Security groups を選択し、Add をクリックします。

   注記

   この例では、グループクレームに、ユーザーがメンバーとなっているすべてのセキュリティーグループを含めます。実際の実稼働環境では、グループクレームに、Red Hat OpenShift Service on AWS に適用するグループのみを含めてください。

   

手順

1. 次のコマンドを実行して変数を作成します。

   $ CLUSTER_NAME=example-cluster 1
   $ IDP_NAME=AAD 2
   $ APP_ID=yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy 3
   $ CLIENT_SECRET=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx 4
   $ TENANT_ID=zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz 5

   1

   これは ROSA クラスターの名前に置き換えます。

   2

   この値は、このプロセスで前に生成した OAuth コールバック URL で使用した名前に置き換えます。

   3

   これはアプリケーション (クライアント) ID に置き換えます。

   4

   これはクライアントシークレットに置き換えます。

   5

   これはディレクトリー (テナント) ID に置き換えます。

2. 次のコマンドを実行して、クラスターの OAuth プロバイダーを設定します。グループクレームを有効にした場合は、必ず --group-claims groups 引数を使用してください。

   • グループクレームを有効にした場合は、次のコマンドを実行します。

     $ rosa create idp \
     --cluster ${CLUSTER_NAME} \
     --type openid \
     --name ${IDP_NAME} \
     --client-id ${APP_ID} \
     --client-secret ${CLIENT_SECRET} \
     --issuer-url https://login.microsoftonline.com/${TENANT_ID}/v2.0 \
     --email-claims email \
     --name-claims name \
     --username-claims preferred_username \
     --extra-scopes email,profile \
     --groups-claims groups

   • グループクレームを有効にしなかった場合は、次のコマンドを実行します。

     $ rosa create idp \
     --cluster ${CLUSTER_NAME} \
     --type openid \
     --name ${IDP_NAME} \
     --client-id ${APP_ID} \
     --client-secret ${CLIENT_SECRET} \
     --issuer-url https://login.microsoftonline.com/${TENANT_ID}/v2.0 \
     --email-claims email \
     --name-claims name \
     --username-claims preferred_username \
     --extra-scopes email,profile

1. 次のコマンドを実行して、ROSA クラスターにログインします。

   $ oc login --token=<your-token> --server=<your-server-url>

   ログイントークンを見つけるには、Red Hat OpenShift Cluster Manager からプルシークレット でクラスターにアクセスします。

2. 次のコマンドを実行して、クラスターに STS があることを検証します。

   $ oc get authentication.config.openshift.io cluster -o json \
     | jq .spec.serviceAccountIssuer

   出力例

   "https://xxxxx.cloudfront.net/xxxxx"

   出力が異なる場合は、続行しないでください。このプロセスを続行する前に、STS クラスターの作成に関する Red Hat ドキュメント を参照してください。

3. 次のコマンドを実行して、CSI ドライバーの実行を許可するように SecurityContextConstraints 権限を設定します。

   $ oc new-project csi-secrets-store
   $ oc adm policy add-scc-to-user privileged \
       system:serviceaccount:csi-secrets-store:secrets-store-csi-driver
   $ oc adm policy add-scc-to-user privileged \
       system:serviceaccount:csi-secrets-store:csi-secrets-store-provider-aws

4. 次のコマンドを実行して、このプロセスで後で使用する環境変数を作成します。

   $ export REGION=$(oc get infrastructure cluster -o=jsonpath="{.status.platformStatus.aws.region}")
   $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster \
      -o jsonpath='{.spec.serviceAccountIssuer}' | sed  's|^https://||')
   $ export AWS_ACCOUNT_ID=`aws sts get-caller-identity --query Account --output text`
   $ export AWS_PAGER=""

1. 次のコマンドを実行し、Helm を使用してシークレットストア CSI ドライバーを登録します。

   $ helm repo add secrets-store-csi-driver \
       https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts

2. 次のコマンドを実行して、Helm リポジトリーを更新します。

   $ helm repo update

3. 次のコマンドを実行して、シークレットストア CSI ドライバーをインストールします。

   $ helm upgrade --install -n csi-secrets-store \
       csi-secrets-store-driver secrets-store-csi-driver/secrets-store-csi-driver

4. 次のコマンドを実行して、AWS プロバイダーをデプロイします。

   $ oc -n csi-secrets-store apply -f \
       https://raw.githubusercontent.com/rh-mobb/documentation/main/content/misc/secrets-store-csi/aws-provider-installer.yaml

5. 次のコマンドを実行して、両方の Daemonset が実行されていることを確認します。

   $ oc -n csi-secrets-store get ds \
       csi-secrets-store-provider-aws \
       csi-secrets-store-driver-secrets-store-csi-driver

6. 次のコマンドを実行して、シークレットストア CSI ドライバーにラベルを付けて、制限付き Pod セキュリティープロファイルとともに使用することを許可します。

   $ oc label csidriver.storage.k8s.io/secrets-store.csi.k8s.io security.openshift.io/csi-ephemeral-volume-profile=restricted

1. 次のコマンドを実行して、Secrets Manager のシークレットを作成します。

   $ SECRET_ARN=$(aws --region "$REGION" secretsmanager create-secret \
       --name MySecret --secret-string \
       '{"username":"shadowman", "password":"hunter2"}' \
       --query ARN --output text)
   $ echo $SECRET_ARN

2. 次のコマンドを実行して、IAM アクセスポリシードキュメントを作成します。

   $ cat << EOF > policy.json
   {
      "Version": "2012-10-17",
      "Statement": [{
         "Effect": "Allow",
         "Action": [
           "secretsmanager:GetSecretValue",
           "secretsmanager:DescribeSecret"
         ],
         "Resource": ["$SECRET_ARN"]
         }]
   }
   EOF

3. 次のコマンドを実行して、IAM アクセスポリシーを作成します。

   $ POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn \
   --output text iam create-policy \
   --policy-name openshift-access-to-mysecret-policy \
   --policy-document file://policy.json)
   $ echo $POLICY_ARN

4. 次のコマンドを実行して、IAM ロール信頼ポリシードキュメントを作成します。

   注記

   信頼ポリシーは、このプロセスで後で作成する namespace のデフォルトのサービスアカウントにロックされます。

   $ cat <<EOF > trust-policy.json
   {
      "Version": "2012-10-17",
      "Statement": [
      {
      "Effect": "Allow",
      "Condition": {
        "StringEquals" : {
          "${OIDC_ENDPOINT}:sub": ["system:serviceaccount:my-application:default"]
         }
       },
       "Principal": {
          "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
       },
       "Action": "sts:AssumeRoleWithWebIdentity"
       }
       ]
   }
   EOF

5. 次のコマンドを実行して、IAM ロールを作成します。

   $ ROLE_ARN=$(aws iam create-role --role-name openshift-access-to-mysecret \
   --assume-role-policy-document file://trust-policy.json \
   --query Role.Arn --output text)
   $ echo $ROLE_ARN

6. 次のコマンドを実行して、ロールをポリシーに割り当てます。

   $ aws iam attach-role-policy --role-name openshift-access-to-mysecret \
       --policy-arn $POLICY_ARN

1. 次のコマンドを実行して、OpenShift プロジェクトを作成します。

   $ oc new-project my-application

2. 次のコマンドを実行して、STS ロールを使用するようにデフォルトのサービスアカウントにアノテーションを付けます。

   $ oc annotate -n my-application serviceaccount default \
       eks.amazonaws.com/role-arn=$ROLE_ARN

3. 次のコマンドを実行して、シークレットにアクセスするためのシークレットプロバイダークラスを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: secrets-store.csi.x-k8s.io/v1
   kind: SecretProviderClass
   metadata:
     name: my-application-aws-secrets
   spec:
     provider: aws
     parameters:
       objects: |
         - objectName: "MySecret"
           objectType: "secretsmanager"
   EOF

4. 次のコマンドでシークレットを使用してデプロイメントを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: my-application
     labels:
       app: my-application
   spec:
     volumes:
     - name: secrets-store-inline
       csi:
         driver: secrets-store.csi.k8s.io
         readOnly: true
         volumeAttributes:
           secretProviderClass: "my-application-aws-secrets"
     containers:
     - name: my-application-deployment
       image: k8s.gcr.io/e2e-test-images/busybox:1.29
       command:
         - "/bin/sleep"
         - "10000"
       volumeMounts:
       - name: secrets-store-inline
         mountPath: "/mnt/secrets-store"
         readOnly: true
   EOF

5. 次のコマンドを実行して、Pod にシークレットがマウントされていることを確認します。

   $ oc exec -it my-application -- cat /mnt/secrets-store/MySecret

1. 次のコマンドを実行してアプリケーションを削除します。

   $ oc delete project my-application

2. 次のコマンドを実行して、シークレットストア CSI ドライバーを削除します。

   $ helm delete -n csi-secrets-store csi-secrets-store-driver

3. 次のコマンドを実行して、Security Context Constraints を削除します。

   $ oc adm policy remove-scc-from-user privileged \
       system:serviceaccount:csi-secrets-store:secrets-store-csi-driver
   $ oc adm policy remove-scc-from-user privileged \
       system:serviceaccount:csi-secrets-store:csi-secrets-store-provider-aws

4. 次のコマンドを実行して、AWS プロバイダーを削除します。

   $ oc -n csi-secrets-store delete -f \
   https://raw.githubusercontent.com/rh-mobb/documentation/main/content/misc/secrets-store-csi/aws-provider-installer.yaml

5. 次のコマンドを実行して、AWS のロールとポリシーを削除します。

   $ aws iam detach-role-policy --role-name openshift-access-to-mysecret \
       --policy-arn $POLICY_ARN
   $ aws iam delete-role --role-name openshift-access-to-mysecret
   $ aws iam delete-policy --policy-arn $POLICY_ARN

6. 次のコマンドを実行して、Secrets Manager のシークレットを削除します。

   $ aws secretsmanager --region $REGION delete-secret --secret-id $SECRET_ARN

1. 次の環境変数を設定し、お使いのクラスターに合わせてクラスター名を変更します。

   $ export CLUSTER_NAME=$(oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"  | sed 's/-[a-z0-9]\{5\}$//')
   $ export REGION=$(rosa describe cluster -c ${ROSA_CLUSTER_NAME} --output json | jq -r .region.id)
   $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o json | jq -r .spec.serviceAccountIssuer | sed  's|^https://||')
   $ export AWS_ACCOUNT_ID=`aws sts get-caller-identity --query Account --output text`
   $ export ACK_SERVICE=s3
   $ export ACK_SERVICE_ACCOUNT=ack-${ACK_SERVICE}-controller
   $ export POLICY_ARN=arn:aws:iam::aws:policy/AmazonS3FullAccess
   $ export AWS_PAGER=""
   $ export SCRATCH="/tmp/${ROSA_CLUSTER_NAME}/ack"
   $ mkdir -p ${SCRATCH}

2. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "Cluster: ${ROSA_CLUSTER_NAME}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"

1. ACK Operator の AWS Identity Access Management (IAM) 信頼ポリシーを作成します。

   $ cat <<EOF > "${SCRATCH}/trust-policy.json"
   {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Condition": {
      "StringEquals" : {
        "${OIDC_ENDPOINT}:sub": "system:serviceaccount:ack-system:${ACK_SERVICE_ACCOUNT}"
      }
    },
    "Principal": {
      "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity"
    }
    ]
   }
   EOF

2. AmazonS3FullAccess ポリシーを割り当てた、ACK Operator が引き受ける AWS IAM ロールを作成します。

   注記

   推奨されるポリシーは、各プロジェクトの GitHub リポジトリー (例: https://github.com/aws-controllers-k8s/s3-controller/blob/main/config/iam/recommended-policy-arn) で見つけることができます。

   $ ROLE_ARN=$(aws iam create-role --role-name "ack-${ACK_SERVICE}-controller" \
      --assume-role-policy-document "file://${SCRATCH}/trust-policy.json" \
      --query Role.Arn --output text)
   $ echo $ROLE_ARN
   
   $ aws iam attach-role-policy --role-name "ack-${ACK_SERVICE}-controller" \
        --policy-arn ${POLICY_ARN}

1. ACK S3 Operator をインストールするプロジェクトを作成します。

   $ oc new-project ack-system

2. ACK S3 Operator の設定を含むファイルを作成します。

   注記

   ACK_WATCH_NAMESPACE は、コントローラーがクラスター内のすべての namespace を適切に監視できるように、意図的に空白のままにします。

   $ cat <<EOF > "${SCRATCH}/config.txt"
   ACK_ENABLE_DEVELOPMENT_LOGGING=true
   ACK_LOG_LEVEL=debug
   ACK_WATCH_NAMESPACE=
   AWS_REGION=${REGION}
   AWS_ENDPOINT_URL=
   ACK_RESOURCE_TAGS=${CLUSTER_NAME}
   ENABLE_LEADER_ELECTION=true
   LEADER_ELECTION_NAMESPACE=
   EOF

3. 前のステップのファイルを使用して ConfigMap を作成します。

   $ oc -n ack-system create configmap \
     --from-env-file=${SCRATCH}/config.txt ack-${ACK_SERVICE}-user-config

4. OperatorHub から ACK S3 Operator をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: ack-${ACK_SERVICE}-controller
     namespace: ack-system
   spec:
     upgradeStrategy: Default
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: ack-${ACK_SERVICE}-controller
     namespace: ack-system
   spec:
     channel: alpha
     installPlanApproval: Automatic
     name: ack-${ACK_SERVICE}-controller
     source: community-operators
     sourceNamespace: openshift-marketplace
   EOF

5. ACK S3 Operator サービスアカウントに、割り当てる AWS IAM ロールのアノテーションを付けて、デプロイメントを再起動します。

   $ oc -n ack-system annotate serviceaccount ${ACK_SERVICE_ACCOUNT} \
     eks.amazonaws.com/role-arn=${ROLE_ARN} && \
     oc -n ack-system rollout restart deployment ack-${ACK_SERVICE}-controller

6. ACK S3 Operator が実行されていることを確認します。

   $ oc -n ack-system get pods

   出力例

   NAME                                 READY   STATUS    RESTARTS   AGE
   ack-s3-controller-585f6775db-s4lfz   1/1     Running   0          51s

1. S3 バケットリソースをデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: s3.services.k8s.aws/v1alpha1
   kind: Bucket
   metadata:
      name: ${CLUSTER-NAME}-bucket
      namespace: ack-system
   spec:
      name: ${CLUSTER-NAME}-bucket
   EOF

2. S3 バケットが AWS で作成されたことを確認します。

   $ aws s3 ls | grep ${CLUSTER_NAME}-bucket

   出力例

   2023-10-04 14:51:45 mrmc-test-maz-bucket

1. S3 バケットリソースを削除します。

   $ oc -n ack-system delete bucket.s3.services.k8s.aws/${CLUSTER-NAME}-bucket

2. ACK S3 Operator と AWS IAM ロールを削除します。

   $ oc -n ack-system delete subscription ack-${ACK_SERVICE}-controller
   $ aws iam detach-role-policy \
     --role-name "ack-${ACK_SERVICE}-controller" \
     --policy-arn ${POLICY_ARN}
   $ aws iam delete-role \
     --role-name "ack-${ACK_SERVICE}-controller"

3. ack-system プロジェクトを削除します。

   $ oc delete project ack-system

1. 次の環境変数を設定します。CLUSTER_NAME はクラスターの名前に置き換えます。

   $ export DOMAIN=apps.<company_name>.io 1
   $ export AWS_PAGER=""
   $ export CLUSTER_NAME=$(oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"  | sed 's/-[a-z0-9]\{5\}$//')
   $ export REGION=$(oc get infrastructure cluster -o=jsonpath="{.status.platformStatus.aws.region}")
   $ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
   $ export SCRATCH="/tmp/${CLUSTER_NAME}/external-dns"
   $ mkdir -p ${SCRATCH}

   1

   カスタムドメイン。

2. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "Cluster: ${CLUSTER_NAME}, Region: ${REGION}, AWS Account ID: ${AWS_ACCOUNT_ID}"

手順

1. 新しいプロジェクトを作成します。

   $ oc new-project external-dns-operator

2. 秘密鍵と公開証明書から新しい TLS シークレットを作成します。fullchain.pem は完全なワイルドカード証明書チェーン (中間証明書を含む)、privkey.pem はワイルドカード証明書の秘密鍵です。

   $ oc -n external-dns-operator create secret tls external-dns-tls --cert=fullchain.pem --key=privkey.pem

3. 新規の CustomDomain カスタムリソース (CR) を作成します。

   external-dns-custom-domain.yaml の例

   apiVersion: managed.openshift.io/v1alpha1
   kind: CustomDomain
   metadata:
     name: external-dns
   spec:
     domain: apps.<company_name>.io 1
     scope: External
     loadBalancerType: NLB
     certificate:
       name: external-dns-tls
       namespace: external-dns-operator

   1

   カスタムドメイン。

4. CR を適用します。

   $ oc apply -f external-dns-custom-domain.yaml

5. カスタムドメイン Ingress Controller がデプロイされ、Ready ステータスになっていることを確認します。

   $ oc get customdomains

   出力例

   NAME               ENDPOINT                                                    DOMAIN                       STATUS
   external-dns       xxrywp.<company_name>.cluster-01.opln.s1.openshiftapps.com  *.apps.<company_name>.io     Ready

1. Amazon Route 53 のパブリックホストゾーン ID を取得します。

   $ export ZONE_ID=$(aws route53 list-hosted-zones-by-name --output json \
     --dns-name "${DOMAIN}." --query 'HostedZones[0]'.Id --out text | sed 's/\/hostedzone\///')

2. External DNS Operator がカスタムドメインのパブリックホストゾーン のみ を更新できるようにする AWS IAM ポリシードキュメントを作成します。

   $ cat << EOF > "${SCRATCH}/external-dns-policy.json"
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "route53:ChangeResourceRecordSets"
         ],
         "Resource": [
           "arn:aws:route53:::hostedzone/${ZONE_ID}"
         ]
       },
       {
         "Effect": "Allow",
         "Action": [
           "route53:ListHostedZones",
           "route53:ListResourceRecordSets"
         ],
         "Resource": [
           "*"
         ]
       }
     ]
   }
   EOF

3. AWS IAM ポリシーを作成します。

   $ export POLICY_ARN=$(aws iam create-policy --policy-name "${CLUSTER_NAME}-AllowExternalDNSUpdates" \
     --policy-document file://${SCRATCH}/external-dns-policy.json \
     --query 'Policy.Arn' --output text)

4. AWS IAM ユーザーを作成します。

   $ aws iam create-user --user-name "${CLUSTER_NAME}-external-dns-operator"

5. ポリシーを割り当てします。

   $ aws iam attach-user-policy --user-name "${CLUSTER_NAME}-external-dns-operator" --policy-arn $POLICY_ARN

   注記

   これは将来的には IRSA を使用した STS に変更される予定です。

6. IAM ユーザーの AWS キーを作成します。

   $ SECRET_ACCESS_KEY=$(aws iam create-access-key --user-name "${CLUSTER_NAME}-external-dns-operator")

7. 静的認証情報を作成します。

   $ cat << EOF > "${SCRATCH}/credentials"
   [default]
   aws_access_key_id = $(echo $SECRET_ACCESS_KEY | jq -r '.AccessKey.AccessKeyId')
   aws_secret_access_key = $(echo $SECRET_ACCESS_KEY | jq -r '.AccessKey.SecretAccessKey')
   EOF

1. OperatorHub から External DNS Operator をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: external-dns-group
     namespace: external-dns-operator
   spec:
     targetNamespaces:
     - external-dns-operator
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: external-dns-operator
     namespace: external-dns-operator
   spec:
     channel: stable-v1.1
     installPlanApproval: Automatic
     name: external-dns-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
   EOF

2. External DNS Operator が実行されるまで待ちます。

   $ oc rollout status deploy external-dns-operator --timeout=300s

3. AWS IAM ユーザー認証情報からシークレットを作成します。

   $ oc -n external-dns-operator create secret generic external-dns \
     --from-file "${SCRATCH}/credentials"

4. ExternalDNS コントローラーをデプロイします。

   $ cat << EOF | oc apply -f -
   apiVersion: externaldns.olm.openshift.io/v1beta1
   kind: ExternalDNS
   metadata:
     name: ${DOMAIN}
   spec:
     domains:
       - filterType: Include
         matchType: Exact
         name: ${DOMAIN}
     provider:
       aws:
         credentials:
           name: external-dns
       type: AWS
     source:
       openshiftRouteOptions:
         routerName: external-dns
       type: OpenShiftRoute
     zones:
       - ${ZONE_ID}
   EOF

5. コントローラーが実行されるまで待ちます。

   $ oc rollout status deploy external-dns-${DOMAIN} --timeout=300s

1. サンプルアプリケーション用に新しいプロジェクトを作成します。

   $ oc new-project hello-world

2. Hello World アプリケーションをデプロイします。

   $ oc new-app -n hello-world --image=docker.io/openshift/hello-openshift

3. カスタムドメイン名を指定してアプリケーションのルートを作成します。

   $ oc -n hello-world create route edge --service=hello-openshift hello-openshift-tls \
   --hostname hello-openshift.${DOMAIN}

4. DNS レコードが ExternalDNS によって自動的に作成されたかどうかを確認します。

   注記

   レコードが Amazon Route 53 に表示されるまでに数分かかる場合があります。

   $ aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} \
      --query "ResourceRecordSets[?Type == 'CNAME']" | grep hello-openshift

5. オプション: TXT レコードを表示して、レコードが ExternalDNS によって作成されたことを確認することもできます。

   $ aws route53 list-resource-record-sets --hosted-zone-id ${ZONE_ID} \
      --query "ResourceRecordSets[?Type == 'TXT']" | grep ${DOMAIN}

6. ブラウザーでカスタムコンソールドメインに移動すると、OpenShift ログインが表示されます。

   $ echo console.${DOMAIN}

1. 次の環境変数を設定します。

   $ export DOMAIN=apps.<company_name>.io 1
   $ export EMAIL=<youremail@company_name.io> 2
   $ export AWS_PAGER=""
   $ export CLUSTER_NAME=$(oc get infrastructure cluster -o=jsonpath="{.status.infrastructureName}"  | sed 's/-[a-z0-9]\{5\}$//')
   $ export OIDC_ENDPOINT=$(oc get authentication.config.openshift.io cluster -o json | jq -r .spec.serviceAccountIssuer | sed  's|^https://||')
   $ export REGION=$(oc get infrastructure cluster -o=jsonpath="{.status.platformStatus.aws.region}")
   $ export AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
   $ export SCRATCH="/tmp/${CLUSTER_NAME}/dynamic-certs"
   $ mkdir -p ${SCRATCH}

   1

   カスタムドメイン。

   2

   Let's Encrypt が証明書に関する通知を送信するために使用するメールアドレス。

2. 次のセクションに進む前に、すべてのフィールドが正しく出力されていることを確認してください。

   $ echo "Cluster: ${CLUSTER_NAME}, Region: ${REGION}, OIDC Endpoint: ${OIDC_ENDPOINT}, AWS Account ID: ${AWS_ACCOUNT_ID}"

1. Amazon Route 53 のパブリックホストゾーン ID を取得します。

   注記

   このコマンドは、DOMAIN 環境変数として以前指定したカスタムドメインに一致するパブリックホストゾーンを検索します。Amazon Route 53 パブリックホストゾーンを手動で指定するには、export ZONE_ID=<zone_ID> を実行し、<zone_ID> を特定の Amazon Route 53 パブリックホストゾーン ID に置き換えます。

   $ export ZONE_ID=$(aws route53 list-hosted-zones-by-name --output json \
     --dns-name "${DOMAIN}." --query 'HostedZones[0]'.Id --out text | sed 's/\/hostedzone\///')

2. 指定したパブリックホストゾーン のみ を更新できる権限を与える cert-manager Operator 用の AWS IAM ポリシードキュメントを作成します。

   $ cat <<EOF > "${SCRATCH}/cert-manager-policy.json"
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "route53:GetChange",
         "Resource": "arn:aws:route53:::change/*"
       },
       {
         "Effect": "Allow",
         "Action": [
           "route53:ChangeResourceRecordSets",
           "route53:ListResourceRecordSets"
         ],
         "Resource": "arn:aws:route53:::hostedzone/${ZONE_ID}"
       },
       {
         "Effect": "Allow",
         "Action": "route53:ListHostedZonesByName",
         "Resource": "*"
       }
     ]
   }
   EOF

3. 前のステップで作成したファイルを使用して IAM ポリシーを作成します。

   $ POLICY_ARN=$(aws iam create-policy --policy-name "${CLUSTER_NAME}-cert-manager-policy" \
     --policy-document file://${SCRATCH}/cert-manager-policy.json \
     --query 'Policy.Arn' --output text)

4. cert-manager Operator の AWS IAM 信頼ポリシーを作成します。

   $ cat <<EOF > "${SCRATCH}/trust-policy.json"
   {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Effect": "Allow",
    "Condition": {
      "StringEquals" : {
        "${OIDC_ENDPOINT}:sub": "system:serviceaccount:cert-manager:cert-manager"
      }
    },
    "Principal": {
      "Federated": "arn:aws:iam::$AWS_ACCOUNT_ID:oidc-provider/${OIDC_ENDPOINT}"
    },
    "Action": "sts:AssumeRoleWithWebIdentity"
    }
    ]
   }
   EOF

5. 前のステップで作成した信頼ポリシーを使用して、cert-manager Operator の IAM ロールを作成します。

   $ ROLE_ARN=$(aws iam create-role --role-name "${CLUSTER_NAME}-cert-manager-operator" \
      --assume-role-policy-document "file://${SCRATCH}/trust-policy.json" \
      --query Role.Arn --output text)

6. 権限ポリシーをロールに割り当てます。

   $ aws iam attach-role-policy --role-name "${CLUSTER_NAME}-cert-manager-operator" \
     --policy-arn ${POLICY_ARN}

1. cert-manager Operator をインストールするプロジェクトを作成します。

   $ oc new-project cert-manager-operator

   重要

   クラスター内で複数の cert-manager Operator を使用しないでください。クラスターにコミュニティーの cert-manager Operator がインストールされている場合は、それをアンインストールしてから cert-manager Operator for Red Hat OpenShift をインストールする必要があります。

2. cert-manager Operator for Red Hat OpenShift をインストールします。

   $ cat << EOF | oc apply -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: openshift-cert-manager-operator-group
     namespace: cert-manager-operator
   spec:
     targetNamespaces:
     - cert-manager-operator
   ---
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: openshift-cert-manager-operator
     namespace: cert-manager-operator
   spec:
     channel: stable-v1
     installPlanApproval: Automatic
     name: openshift-cert-manager-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
   EOF

   注記

   この Operator がインストールされ、セットアップが完了するまでに数分かかります。

3. cert-manager Operator が実行されていることを確認します。

   $ oc -n cert-manager-operator get pods

   出力例

   NAME                                                        READY   STATUS    RESTARTS   AGE
   cert-manager-operator-controller-manager-84b8799db5-gv8mx   2/2     Running   0          12s

4. cert-manager Pod によって使用されるサービスアカウントに、前に作成した AWS IAM ロールのアノテーションを付けます。

   $ oc -n cert-manager annotate serviceaccount cert-manager eks.amazonaws.com/role-arn=${ROLE_ARN}

5. 次のコマンドを実行して、既存の cert-manager コントローラー Pod を再起動します。

   $ oc -n cert-manager delete pods -l app.kubernetes.io/name=cert-manager

6. DNS-01 チャレンジ解決の問題を防ぐために、外部ネームサーバーを使用するように Operator の設定にパッチを適用します。

   $ oc patch certmanager.operator.openshift.io/cluster --type merge \
     -p '{"spec":{"controllerConfig":{"overrideArgs":["--dns01-recursive-nameservers-only","--dns01-recursive-nameservers=1.1.1.1:53"]}}}'

7. 次のコマンドを実行して、Let's Encrypt を使用する ClusterIssuer リソースを作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: letsencrypt-production
   spec:
     acme:
       server: https://acme-v02.api.letsencrypt.org/directory
       email: ${EMAIL}
       # This key doesn't exist, cert-manager creates it
       privateKeySecretRef:
         name: prod-letsencrypt-issuer-account-key
       solvers:
       - dns01:
           route53:
            hostedZoneID: ${ZONE_ID}
            region: ${REGION}
            secretAccessKeySecretRef:
              name: ''
   EOF

8. ClusterIssuer リソースの準備ができていることを確認します。

   $ oc get clusterissuer.cert-manager.io/letsencrypt-production

   出力例

   NAME                     READY   AGE
   letsencrypt-production   True    47s

1. 新しいプロジェクトを作成します。

   $ oc new-project custom-domain-ingress

2. 証明書リソースを作成して設定し、カスタムドメイン Ingress Controller の証明書をプロビジョニングします。

   注記

   次の例では、単一のドメイン証明書を使用します。SAN およびワイルドカード証明書もサポートされています。

   $ cat << EOF | oc apply -f -
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: custom-domain-ingress-cert
     namespace: custom-domain-ingress
   spec:
     secretName: custom-domain-ingress-cert-tls
     issuerRef:
        name: letsencrypt-production
        kind: ClusterIssuer
     commonName: "${DOMAIN}"
     dnsNames:
     - "${DOMAIN}"
   EOF

3. 証明書が発行されたことを確認します。

   注記

   Let's Encrypt によってこの証明書が発行されるまでに数分かかります。5 分以上かかる場合は、oc -n custom-domain-ingress describe certificate.cert-manager.io/custom-domain-ingress-cert を実行して、cert-manager によって報告される問題を確認します。

   $ oc -n custom-domain-ingress get certificate.cert-manager.io/custom-domain-ingress-cert

   出力例

   NAME                         READY   SECRET                           AGE
   custom-domain-ingress-cert   True    custom-domain-ingress-cert-tls   9m53s

4. 新規の CustomDomain カスタムリソース (CR) を作成します。

   $ cat << EOF | oc apply -f -
   apiVersion: managed.openshift.io/v1alpha1
   kind: CustomDomain
   metadata:
     name: custom-domain-ingress
   spec:
     domain: ${DOMAIN}
     scope: External
     loadBalancerType: NLB
     certificate:
       name: custom-domain-ingress-cert-tls
       namespace: custom-domain-ingress
   EOF

5. カスタムドメイン Ingress Controller がデプロイされ、Ready ステータスになっていることを確認します。

   $ oc get customdomains

   出力例

   NAME                    ENDPOINT                                                               DOMAIN            STATUS
   custom-domain-ingress   tfoxdx.custom-domain-ingress.cluster.1234.p1.openshiftapps.com         example.com       Ready

6. カスタムドメイン Ingress Controller の DNS 解決を有効にするために必要な DNS 変更を含むドキュメントを準備します。

   $ INGRESS=$(oc get customdomain.managed.openshift.io/custom-domain-ingress --template={{.status.endpoint}})
   $ cat << EOF > "${SCRATCH}/create-cname.json"
   {
     "Comment":"Add CNAME to custom domain endpoint",
     "Changes":[{
         "Action":"CREATE",
         "ResourceRecordSet":{
           "Name": "*.${DOMAIN}",
         "Type":"CNAME",
         "TTL":30,
         "ResourceRecords":[{
           "Value": "${INGRESS}"
         }]
       }
     }]
   }
   EOF

7. 変更を伝播するために Amazon Route 53 に送信します。

   $ aws route53 change-resource-record-sets \
     --hosted-zone-id ${ZONE_ID} \
     --change-batch file://${SCRATCH}/create-cname.json

   注記

   ワイルドカード CNAME レコードを使用すると、カスタムドメイン Ingress Controller を使用してデプロイする新しいアプリケーションごとに新しいレコードを作成する必要がなくなりますが、これらの各アプリケーションが使用する証明書は、ワイルドカード証明書 ではありません。

1. cert-manager による OpenShift ルートの証明書の管理に必要な OpenShift リソースを作成します。

   このステップでは、クラスター内のアノテーション付きルートを特別に監視する新しいデプロイメント (とその Pod) を作成します。新しいルートで issuer-kind および issuer-name アノテーションが検出された場合、ルートの作成時に指定されたホスト名を受け入れる、このルートに固有の新しい証明書を発行者 (この場合は ClusterIssuer) に要求します。

   注記

   クラスターから GitHub にアクセスできない場合は、raw コンテンツをローカルに保存し、oc apply -f localfilename.yaml -n cert-manager を実行します。

   $ oc -n cert-manager apply -f https://github.com/cert-manager/openshift-routes/releases/latest/download/cert-manager-openshift-routes.yaml

   このステップでは、次の追加の OpenShift リソースも作成されます。

   • ClusterRole - クラスター全体のルートを監視および更新する権限を付与します。
   • ServiceAccount - 新しく作成された Pod を実行する権限を使用します。
   • ClusterRoleBinding - これら 2 つのリソースをバインドします。

2. 新しい cert-manager-openshift-routes Pod が正常に実行されていることを確認します。

   $ oc -n cert-manager get pods

   結果の例:

   NAME                                             READY   STATUS    RESTARTS   AGE
   cert-manager-866d8f788c-9kspc                    1/1     Running   0          4h21m
   cert-manager-cainjector-6885c585bd-znws8         1/1     Running   0          4h41m
   cert-manager-openshift-routes-75b6bb44cd-f8kd5   1/1     Running   0          6s
   cert-manager-webhook-8498785dd9-bvfdf            1/1     Running   0          4h41m

1. サンプルアプリケーション用に新しいプロジェクトを作成します。

   $ oc new-project hello-world

2. Hello World アプリケーションをデプロイします。

   $ oc -n hello-world new-app --image=docker.io/openshift/hello-openshift

3. クラスターの外部からアプリケーションを公開するためのルートを作成します。

   $ oc -n hello-world create route edge --service=hello-openshift hello-openshift-tls --hostname hello.${DOMAIN}

4. ルートの証明書が信頼されていないことを確認します。

   $ curl -I https://hello.${DOMAIN}

   出力例

   curl: (60) SSL: no alternative certificate subject name matches target host name 'hello.example.com'
   More details here: https://curl.se/docs/sslcerts.html
   
   curl failed to verify the legitimacy of the server and therefore could not
   establish a secure connection to it. To learn more about this situation and
   how to fix it, please visit the web page mentioned above.

5. ルートにアノテーションを付けて、cert-manager をトリガーしてカスタムドメインの証明書をプロビジョニングします。

   $ oc -n hello-world annotate route hello-openshift-tls cert-manager.io/issuer-kind=ClusterIssuer cert-manager.io/issuer-name=letsencrypt-production

   注記

   証明書の作成には 2 - 3 分かかります。証明書の更新は、有効期限が近づくと、cert-manager Operator によって自動的に処理されます。

6. ルートの証明書が信頼されていることを確認します。

   $ curl -I https://hello.${DOMAIN}

   出力例

   HTTP/2 200
   date: Thu, 05 Oct 2023 23:45:33 GMT
   content-length: 17
   content-type: text/plain; charset=utf-8
   set-cookie: 52e4465485b6fb4f8a1b1bed128d0f3b=68676068bb32d24f0f558f094ed8e4d7; path=/; HttpOnly; Secure; SameSite=None
   cache-control: private

1. 次のコマンドを実行して管理ユーザーを作成します。

   rosa create admin --cluster=<cluster-name>

   出力例

   W: It is recommended to add an identity provider to login to this cluster. See 'rosa create idp --help' for more information.
   I: Admin account has been added to cluster 'my-rosa-cluster'. It may take up to a minute for the account to become active.
   I: To login, run the following command:
   oc login https://api.my-rosa-cluster.abcd.p1.openshiftapps.com:6443 \
   --username cluster-admin \
   --password FWGYL-2mkJI-00000-00000

2. 前のステップで返されたログインコマンドをコピーし、ターミナルに貼り付けます。これにより、CLI を使用してクラスターにログインし、クラスターの使用を開始できるようになります。

   $ oc login https://api.my-rosa-cluster.abcd.p1.openshiftapps.com:6443 \
   >    --username cluster-admin \
   >    --password FWGYL-2mkJI-00000-00000

   出力例

   Login successful.
   
   You have access to 79 projects, the list has been suppressed. You can list all projects with ' projects'
   
   Using project "default".

3. 管理ユーザーとしてログインしていることを確認するには、次のコマンドのいずれかを実行します。

   • オプション 1:

     $ oc whoami

     出力例

     cluster-admin

   • オプション 2:

     oc get all -n openshift-apiserver

     このコマンドをエラーなしで実行できるのは管理ユーザーのみです。

4. これでクラスターを管理ユーザーとして使用できるようになりました。このチュートリアルではこれで十分です。実際のデプロイメントでは、アイデンティティープロバイダーをセットアップすることを強く推奨します。これについては、次のチュートリアル で説明します。