前回の記事 ではHCPの概要やメリットについて触れましたが、本記事では実際にROSA HCPクラスターを構築する手順を徹底解説します。 各種CLIツールのインストールから、ROSA特有のIAMロールの作成、そして実際のクラスターデプロイと接続確認まで、ハンズオン形式で一通り実践できる内容となっています。 「ROSAを触ってみたいけれど、何から始めればいいか分からない」という方は、ぜひ手元の環境で実際に構築してみてください。 ROSA構築のための事前準備 ROSA（Red Hat OpenShift on AWS）でクラスターを実際に作成していくにあたって、事前に必要となるアカウントや環境は以下の通りです。 AWSアカウント この記事では、AWSアカウントが作成済みであることを前提としています。 補足：ROSAの構築には適切なIAM権限（AdministratorAccessなど）が必要になります。 Red Hatアカウント この記事では、Red Hatアカウントが作成済みであることを前提としています。 まだ作成していない場合は、 Red Hatの公式サイト からアカウントを作成してください。 AWSアカウントとRed Hatアカウントの紐づけ AWSコンソールから、Red Hat OpenShift Service on AWS (ROSA)ページに移動し、「使用を開始」をクリックします。 ROSA HCPを有効化にし、「Red Hatに進む」でRed Hat側でアカウントを紐づけてください。 ターミナル この記事では、Windowsの WSL（Ubuntu） を使用して構築を進めていきます。 macOS: 標準のターミナル（bash/zsh）であれば、基本的にそのまま同様の手順で進行可能です。 その他（GitBash, PowerShellなど）: コマンドの挙動が異なる場合があり、動作を保証できませんのでご注意ください。 注意事項 ROSAの構築・利用にあたっては、 AWSのインフラ利用料およびRed Hatのサブスクリプション料金（従量課金など）が発生します 。 予期せぬ課金を防ぐため、検証が終わったら必ずクラスターを削除するなど、料金面についてあらかじめご承知おきください。 環境設定 それでは、実際にROSA構築に入る前に、必要なツール（CLI）をインストールしていきましょう。 ROSAの構築・操作には、基本的に以下の3つのCLIを利用します。 AWS CLI ROSA CLI OpenShift CLI AWS CLIのインストール ROSAはAWSのマネジードサービスであるため、AWSアカウントにログインしている状態で利用できます。まずは、以下のコマンドでAWS CLIをインストールします。 # インストーラーのダウンロードと解凍 $ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" $ sudo apt update && sudo apt install -y unzip $ unzip awscliv2.zip # インストール実行 $ sudo ./aws/install # インストール確認 $ aws --version ROSA CLIのインストール ROSA CLIは、ROSAクラスターの新規作成や、クラスター全体のステータス確認・削除など、クラスター単位の操作で使用するCLIです。 以下のコマンドでROSA CLIをインストールします。 # ダウンロードと解凍 $ curl -L https://github.com/openshift/rosa/releases/download/v1.2.60/rosa_Linux_x86_64.tar.gz -o rosa-linux.tar.gz $ tar xvzf rosa-linux.tar.gz # binaryディレクトリに移動 $ sudo mv ./rosa /usr/local/bin/ # インストール確認 $ rosa version OpenShift CLIのインストール OpenShift CLI（oc）は、作成したROSAクラスターの内部にある各種リソース（NodeやPodなど）を操作するためのCLIです。KubernetesのkubectlのOpenShift拡張版とイメージしていただければ大丈夫です。 以下のコマンドでOpenShift CLIをインストールします。 # ダウンロードと解凍 $ curl -LO https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.20.12/openshift-client-linux.tar.gz $ tar -xvf openshift-client-linux.tar.gz # binaryディレクトリに移動 $ sudo mv ./oc ./kubectl /usr/local/bin/ # インストール確認 $ oc version client ROSAへのログイン 各種CLIの準備ができたら、実際にアカウントへログインしてみましょう。まずROSAを操作するために、AWSへのログイン（認証）を行います。 $ aws login --remote コマンドを実行すると、https://us-east-1.signin.aws.amazon.com/v1/authorize?response_type=…というURLが表示されるのでブラウザで接続します。 Copy verification codeをクリックしてコピーした認証コードをターミナルのEnter the authorization code displayed in your browser:のところに貼り付けます。 ログイン完了後、以下のコマンドを実行し、認証情報を現在のシェル環境変数にエクスポートしておきます。 $ eval $(aws configure export-credentials --format env) 正しくログインできているか、接続中のAWSアカウント情報を確認してみましょう。   $ aws sts get-caller-identity AWSにログインできたら、次はROSAにログインします。 $ rosa login --use-device-code コマンドを実行すると、以下のようにURLと認証用のコード（ XXXX-XXXX 部分）がターミナルに表示されます。 INFO: To login, navigate to https://sso.redhat.com/device on another device and enter code XXXX-XXXX 提示されたURL（https://sso.redhat.com/device）をブラウザで開き、ターミナルに表示されているコードを入力してサインインを承認してください。 ROSAへのログインが完了したら、クラスターを構築するデフォルトのリージョンを指定しておきます（ここではus-east-1を指定しています）。 $ export AWS_REGION=us-east-1 最後に、以下のコマンドで接続中のROSAのアカウント情報を確認し、正しく表示されたら、ROSAのクラスターを作る準備はすべて完了です。 $ rosa whoami # 出力例 W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64). W: It is recommended that you update to the latest version. AWS ARN: arn:aws:iam::123456789:XXXXXX AWS Account ID: 123456789 AWS Default Region: us-east-1 OCM API: https://api.openshift.com OCM Account Email: XXXXXX OCM Account ID: XXXXXXXX OCM Account Name: XXXXX OCM Account Username: XXXXXXXX もしこのようなエラーが出てきたら、AWS CLIのセッション切れが原因です。 E: Failed to create AWS client: operation error STS: GetCallerIdentity, https response error StatusCode: 403, RequestID: 76d46612-1094-49a6-a78c-4635978a2a42, api error ExpiredToken: The security token included in the request is expired 以下のコマンドで認証情報を更新してください。 $ unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN AWS_CREDENTIAL_EXPIRATION $ eval $(aws configure export-credentials --format env) その後再度rosaコマンドを試してみてください。 クラスター構築 Account Roleの作成 Account Role（アカウントロール）は、Red Hat側がユーザーのAWSアカウント内でクラスターの構築や運用を行うために、安全に権限を委譲するためのIAMロールです。 AWSアカウント単位の共通権限となるため、ユーザーのAWSアカウントにつき1回だけ生成すれば、以降は使い回すことができます。 以下のコマンドで必要なAccount Roleが一括で自動作成されます。 $ rosa create account-roles --hosted-cp --mode auto –hosted-cpというのは、前回の記事で紹介したHCP（Hosted Control Planes）方式に最適化されたAccount Roleを生成するという指定です。 Classic方式との一番大きな違いは、ControlPlane-Role（コントロールプレーン用のロール）が作成されない点です。HCP方式では、コントロールプレーンはRed Hat側で管理するため、ユーザーのAWSアカウント側にIAMロールを生成する必要がありません。 具体的には以下の3つのロールが生成されます。ManagedOpenShift はデフォルトのプレフィックス名です。プレフィックスを指定したい場合は、–prefix <指定したいプレフィックス名> で設定可能です。 ManagedOpenShift-HCP-ROSA-Installer-Role: クラスターの基盤となるVPCやEC2などを自動で組み立てるための権限。 ManagedOpenShift-HCP-ROSA-Support-Role: Red HatのSREチームが障害発生時などにクラスターの状況を調査・対応するための権限。 ManagedOpenShift-HCP-ROSA-Worker-Role: アプリケーションが起動するワーカーノード（EC2インスタンス）が、AWSの他の機能（ストレージなど）を操作するための権限。 作成されたAccount Roleは以下のコマンドで確認できます。 $ rosa list account-roles # 出力例 ROLE NAME ROLE TYPE ROLE ARN OPENSHIFT VERSION AWS Managed ManagedOpenShift-HCP-ROSA-Worker-Role Worker arn:aws:iam::XXXXXXXXXXXX:role/ManagedOpenShift-HCP-ROSA-Worker-Role 4.21 Yes ManagedOpenShift-HCP-ROSA-Installer-Role Installer arn:aws:iam::XXXXXXXXXXXX:role/ManagedOpenShift-HCP-ROSA-Installer-Role 4.21 Yes ManagedOpenShift-HCP-ROSA-Support-Role Support arn:aws:iam::XXXXXXXXXXXX:role/ManagedOpenShift-HCP-ROSA-Support-Role 4.21 Yes Operator Roleの作成 上で作成したAccount Roleは、Red Hat側がユーザーのAWSアカウントを利用して作業するための権限でしたが、Operator Roleは、OpenShiftの内部からAWSリソースを直接操作するためのIAMロールです。 OpenShiftの内部では、ネットワーク管理やストレージ管理、ログ管理など、それぞれの役割に特化した「Operator（オペレーター）」と呼ばれる複数のプログラムが動いています。それらのプログラムがAWSリソース（ロードバランサーやEBSなど）を自動で作成・管理することになるため、各Operatorに必要な最小限の操作権限だけIAMロールとして切り出して、割り当てる仕組みになっています。 また、OperatorにAWSのアクセスキーなどの永続的な認証情報を持たせるのを防ぐため、「AWS STS（AWS Security Token Service）」という仕組みを利用して、OIDCプロバイダーと連携し安全に一時的な操作権限を受け取れるようにします。 そのため、Operator Roleを作成する前に、連携先となるOIDCプロバイダーを用意する必要があります。 以下のコマンドでOpenID Connect Config（oidc-config）を作成することで、AWS側にもOIDCプロバイダーが自動で作成されます。 $ rosa create oidc-config --mode=auto --managed=true --yes 作成できたら、以下のコマンドで生成されたOIDC Configの情報を確認しましょう。 $ rosa list oidc-config # 出力例 ID MANAGED ISSUER URL SECRET ARN XXXXXXXXX true XXXXXXXXX 出力結果に表示される IDはこの後の手順で利用するため、手元に控えておきます。 準備が整ったら、以下のコマンドでOperator Roleを生成します。 $ rosa create operator-roles --hosted-cp --mode auto \ --prefix=demo \ --oidc-config-id=<上で作成されたOIDC ConfigのID> \ --installer-role-arn=<上で作成されたInstaller-RoleのARN> 以下のコマンドで作成されたOperator Roleを確認できます。 $ rosa list operator-roles # 出力例 ROLE PREFIX AMOUNT IN BUNDLE 　demo 　　　　　　　　8 具体的なAWSのリソースとしては、以下のロールが自動生成されます。 補足：IAMロール名がプレフィックス値を含めて64文字を超える場合は、64文字になるように末尾が切り捨てられます。 <prefix>-openshift-ingress-operator-cloud-credentials ：ユーザーがアプリを外部公開する際に、AWS側にロードバランサー（ALBやNLB）を自動作成したり、Route 53のDNS設定を管理したりする権限。 <prefix>-openshift-cloud-network-config-controller-cloud-credential ：OpenShift内部のネットワークと、AWSのネットワークを連動させるための権限。 <prefix>-openshift-cluster-csi-drivers-ebs-cloud-credentials ：AWSのEBSをコンテナのストレージとして割り当てるための権限。 <prefix>-openshift-image-registry-installer-cloud-credentials ：コンテナイメージを保存するためにAWSのS3バケットを生成・操作するための権限。 また、従来のClassic方式と比べると、HCP方式ではコントロールプレーンが分離されているため、kube-system-〜 から始まるHCP専用のOperator Roleも生成されます。 <prefix>-kube-system-capa-controller-manager ：ワーカーノード（EC2）の台数を自動で増減させる機能の権限（オートスケーリングなど）。 <prefix>-kube-system-control-plane-operator ：Red Hat側のコントロールプレーンからの指示でユーザーのAWS環境のインフラを操作できる権限。 <prefix>-kube-system-kube-controller-manager ：Kubernetesの標準的な管理プログラムが、AWSのリソースを監視できるようにする権限。 <prefix>-kube-system-kms-provider ：AWSのKMSと連携し、Kubernetesのシークレットを暗号化するための権 VPCとサブネットの作成 ROSAクラスタをインストールするVPCを作成します。今回はAWSコンソールで簡単に構築してみます。 AWSでVPCを開き、「 お使いのVPC」で VPCを作成を選択します。 VPCだけでなくサブネットやNAT Gatewayも一緒に作成するために「VPCなど」を選択します。 選択後の各種設定値は、以下の表を参考にしてください。表に記載がない項目はデフォルト（初期状態）のままで問題ありません。今回はデモのために作るので、なるべく最小限必要な構成にしています。 パラメータ 説明 名前タグの自動生成 任意の名前（例：rosa-demoなど） アベイラビリティゾーン (AZ) の数 1 パブリックサブネットの数 1 プライベートサブネットの数 1 NAT ゲートウェイ Zonal（1 AZ 内に配置） VPC エンドポイント なし すべての設定が終わったら、画面一番下にある 「VPC を作成」 ボタンを押します。 （作成完了には数分程度かかります） また、subnet-から始まるパブリックサブネットのIDとプライベートサブネットのIDはこのあとのクラスター作成で使うため、テキストエディタ等にメモしておいてください。 ROSAクラスター作成 Account RoleとOperator Role、そして事前にAWS側に用意したVPC（サブネット）の準備ができたら、以下のコマンドを実行してクラスターを作成します。 $ rosa create cluster --cluster-name <クラスター名> \ --sts \ --mode auto \ --hosted-cp \ --subnet-ids <パブリックサブネットID>,<プライベートサブネットID> \ --oidc-config-id <上で作成されたOIDC ConfigのID> \ --operator-roles-prefix <Operator Roleを作成するときに指定したprefix> \ 　--domain-prefix <クラスターのURLのサブドメイン名> \ --yes 各パラメータの説明 パラメータ 説明 –cluster-name 作成するクラスターの一意の名前。任意の英数字で指定。 –sts AWSの安全な一時認証（Security Token Service）を使用するという指定。HCP方式では必須。 –mode auto 途中の質問に対して、すべて自動（デフォルト値）で作成を進めるための指定。 –hosted-cp  HCP方式 でクラスターを作成するためのフラグ。 –subnet-ids クラスターを配置するAWSの既存サブネット（パブリックとプライベート）のIDをカンマ区切りで指定。 –oidc-config-id Operator Role作成時に指定したprefixの値（例: demo）を指定。 –operator-roles-prefix 前の手順で作ったOperator Role群を識別するための接頭辞（例: ManagedOpenShift）を指定。 –domain-prefix 自動生成されるクラスターのURL（管理画面やAPIサーバーのURL）のサブドメイン部分をカスタマイズするための設定（オプション）。 –yes コマンド実行時の最終確認（Are you sure?）をスキップするフラグ。 クラスターの作成が完了するまではおよそ10分〜15分程度かかります。バックグラウンドでどのように構築が進んでいるかリアルタイムで確認したい場合は、以下のコマンドを実行してください。 $ rosa logs install --cluster <クラスター名> --watch # 出力例 bak@1010-00867:~$ rosa logs install -c rosa-demo --watch W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64). W: It is recommended that you update to the latest version. I: Cluster 'rosa-demo' is in validating state waiting for installation to begin. Logs will show up within 5 minutes \ 0001-01-01 00:00:00 +0000 UTC hostedclusters rosa-demo Version 2026-07-13 07:04:09 +0000 UTC hostedclusters rosa-demo Condition not found in the CVO. 2026-07-13 07:04:09 +0000 UTC hostedclusters rosa-demo The hosted control plane is not found 以下のようなログが出たら、ROSAクラスターのデプロイは完了です。 I: Cluster 'rosa-demo' is now ready 接続確認 クラスターの構築が完了したら、実際にログインして接続確認を行いましょう。 接続するためには、まず管理者アカウントである cluster-admin を作成する必要があります。 以下のコマンドでcluster-adminを作成します。コマンドを実行すると、passwordが自動生成され、そのままログインできるコマンド（oc login〜）がターミナルに出力されます。 $ rosa create admin --cluster=<クラスター名> # 出力例 I: Admin account has been added to cluster 'your-cluster-name'. I: Please securely store this generated password. If you lose this password you can delete and recreate the cluster admin user. I: To login, run the following command: oc login https://api.your-cluster-name.xxxx.p1.openshiftapps.com:443 --username cluster-admin --password XXXXX-XXXXX-XXXXX-XXXXX 以下のようにoc loginコマンドを入力してLogin successful. と表示されれば、CLIからの接続確認は完了です。 $ oc login https://api.your-cluster-name.xxxx.p1.openshiftapps.com:443 --username cluster-admin --password XXXXX-XXXXX-XXXXX-XXXXX Login successful. もし、以下のエラーが出たら、数分待ってから再度試してみてください。 Login failed (401 Unauthorized) Verify you have provided the correct credentials. また、CLIからだけでなく、ウェブブラウザを使って管理コンソール（GUI）にログインする方法もあります。 以下のコマンドを実行して、出力結果から「Console URL」の項目を確認します。 $ rosa describe cluster --cluster=<作成したクラスター名> #出力例 W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64). W: It is recommended that you update to the latest version. Name: rosa-demo Domain Prefix: rosa-demo Display Name: rosa-demo ID: XXXXXXXXXX External ID: XXXXXXXXXX Control Plane: ROSA Service Hosted OpenShift Version: 4.20.28 Channel Group: stable DNS: XXXXXXXXXX AWS Account: XXXXXXXXXX AWS Billing Account: XXXXXXXXXX API URL: XXXXXXXXXX Console URL: https://console-openshift-console.apps.rosa.xxxxx.openshiftapps.com Console URLをブラウザに入力してアクセスすると、以下のように管理コンソールに接続できますので、CLIでのログイン（oc login）時に使用した、管理者（cluster-admin）のusernameとpasswordを入力してログインします。 このような画面が出たら管理コンソールにログイン成功です。 (オプション)後片付け ROSAを構築するために作成した各種リソースは費用が発生するので、もし今後使わないのであれば片付けておくことをおすすめします。 また、漏れなく削除するために以下の記載順で削除していくことをおすすめします。 1. クラスターの削除 まず、以下のコマンドでクラスターを削除します。 $ rosa delete cluster --cluster=<クラスター名> --yes 削除中のログの確認は以下のコマンドでできます。 $ rosa logs uninstall --cluster=<クラスター名> --watch 実行例です。 $ rosa logs uninstall --cluster=rosa-demo --watch W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64). W: It is recommended that you update to the latest version. 2026-07-13 07:41:44 +0000 UTC hostedclusters rosa-demo invalid service account signing key: failed to get hostedcluster ServiceAccountSigningKey secret bound-service-account-signing-key: Secret "bound-service-account-signing-key" not found 2026-07-13 07:41:45 +0000 UTC hostedclusters rosa-demo pull secret unavailable: Secret "rosa-demo-pull" not found 2026-07-13 07:41:46 +0000 UTC hostedclusters rosa-demo Reconciliation completed successfully 2026-07-13 07:45:48 +0000 UTC hostedclusters rosa-demo All is well 2026-07-13 07:45:49 +0000 UTC hostedclusters rosa-demo ValidAWSIdentityProvider StatusUnknown 2026-07-13 07:45:49 +0000 UTC hostedclusters rosa-demo All guest resources destroyed I: Cluster 'rosa-demo' completed uninstallation 「Cluster ‘XXXXXX’ completed uninstallation」というログが出たら削除完了です。 クラスターの削除が完了したら、AWSコンソールの「VPC」サービス画面を開き、AWSのリソースを削除していきます。 2. NATゲートウェイの削除 VPCコンソール ＞ 左メニューの「NAT ゲートウェイ」に移動し、作成したNATゲートウェイを削除します。削除済み（Deleted）になるまで数分かかることがあります。 3. VPCの削除 VPCコンソール ＞ 左メニューの「お使いの VPC」に移動し、作成したVPCを選択し削除します。VPCを削除すると、以下の関連リソースもすべて削除されます。 サブネット（パブリック / プライベート） ルートテーブル インターネットゲートウェイ（IGW） セキュリティグループ ※注意：VPCの削除でエラーが出る場合 クラスターの削除完了直後にVPCを消そうとすると、「eni-xxxx (VPC Endpoint Interface) が使用中（in use）のため削除できません」というエラーが出る場合があります。 5分ほど待つか、AWSコンソールの「VPC」＞「エンドポイント」から対象のID（vpce-xxxx）を手動で削除してから、再度VPCの削除を行ってください。 4. Elastic IP（EIP）の解放 VPCコンソール ＞ 左メニューの「Elastic IP」に移動し、NATゲートウェイ用に自動取得されていたElastic IPを選択し、画面右上の「アクション」＞「Elastic IP アドレスの解放」をクリックします。 これでクラスターと関連リソースの削除は完了です。 5. オペレーターロールの削除 $ rosa delete operator-roles --prefix=<プレフィックス名> --mode=auto --yes 以下は実行例です。 $ rosa delete operator-roles --prefix=demo --mode=auto --yes W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64). W: It is recommended that you update to the latest version. I: Fetching operator roles for the prefix: demo I: Deleting operator role 'demo-kube-system-capa-controller-manager' I: Deleting operator role 'demo-kube-system-control-plane-operator' I: Deleting operator role 'demo-kube-system-kms-provider' I: Deleting operator role 'demo-kube-system-kube-controller-manager' I: Deleting operator role 'demo-openshift-cloud-network-config-controller-cloud-credentials' I: Deleting operator role 'demo-openshift-cluster-csi-drivers-ebs-cloud-credentials' I: Deleting operator role 'demo-openshift-image-registry-installer-cloud-credentials' I: Deleting operator role 'demo-openshift-ingress-operator-cloud-credentials' I: Successfully deleted the operator roles 6. OIDC Configの削除 $ rosa delete oidc-config --oidc-config-id=<OIDCのID> --mode=auto --yes 以下は実行例です。 $ rosa delete oidc-config --oidc-config-id 2reuclobhhsao2hdrjpc43lcoq5151go W: The current version (1.2.60) is not up to date with latest rosa cli released version (1.2.64). W: It is recommended that you update to the latest version. ? OIDC Config deletion mode: auto ? Delete the OIDC provider 'arn:aws:iam::XXXXXXXXXXXX:oidc-provider/oidc.op1.openshiftapps.com/2reuclobhhsao2hdrjpc43lcoq5151go'? Yes I: Successfully deleted the OIDC provider arn:aws:iam::XXXXXXXXXXXX:oidc-provider/oidc.op1.openshiftapps.com/2reuclobhhsao2hdrjpc43lcoq5151go I: Registered OIDC Config ID '2reuclobhhsao2hdrjpc43lcoq5151go' has been removed from OCM and can no longer be used まとめ 以上で、ROSAクラスターの構築に必要な事前準備から、各種IAMロールの作成、実際のデプロイ、そして接続確認までの一連の手順が完了しました。 「ROSAって名前は聞くけど、具体的にどうやって始めれば良いんだろう？」という漠然とした疑問やハードルが、この記事を通して少しでも解消できたら幸いです。 次回からは、ログの保管やメトリクスの転送など、クラスターの内部をさらに充実させていく内容を紹介していきます。ぜひ楽しみにしていてください。 参考資料 Getting started with Red Hat OpenShift Service on AWS ( Red Hat Documentation ) Chapter 2. Creating Red Hat OpenShift Service on AWS clusters using the default options（ Red Hat Documentation） Create a ROSA with HCP cluster using the ROSA CLI（Red Hat Documentation） Hosted Control Planes（rosaworkshop.io） ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ROSA（Red Hat OpenShift Service on AWS）を利用したコンテナプラットフォーム構築 ~クラスタ構築~ first appeared on SIOS Tech Lab .

本記事では、AWSとRed Hatが共同提供するフルマネージドなOpenShiftサービス「ROSA」について紹介します。 特に、近年の主流であり、インフラ費用や運用負荷を劇的に削減できるROSAの最新アーキテクチャモデル「HCP（Hosted Control Planes）」の仕組みと、導入による4つのメリットを分かりやすく紹介し、最適なコンテナ基盤選定のヒントをお届けします。 ROSAとは ROSA（Red Hat OpenShift Service on AWS）とは、Red Hatが提供しているコンテナオーケストレーションプラットフォームであるOpenShiftを、AWS上のフルマネージドサービスとして利用できるようにしたサービスです。（ OpenShiftについて詳しく知りたい方は、 こちら の記事をご参考ください） ROSAを利用してコンテナ基盤を運用することには、以下の利点があります。 Red HatとAWSの共同サポート ROSAは、サポート窓口が完全に一元化されていて、問い合わせを受けると、裏側でAWSとRed Hatのエンジニアが直接連携して原因を突き止めてくれる仕組みになっています。自分たちでAWS上にOpenShiftを構築した場合、トラブルが起きると「AWSのインフラが悪いのか、それともOpenShiftのバグなのか」を自力で調べ、それぞれのサポートに別々に問い合わせなければなりません。ROSAであればそのようなアクションが一切不要になるため、運用の負担を大きく軽減できます。 Red Hatの専門チームによる24時間監視 ROSAのクラスターは、Red HatのSREチームによって24時間365日体制で監視・運用されるようになります。 クラスターに何か障害が起きても、Red HatのSREチームが裏側で迅速に対応・復旧をしてくれるため、ユーザーとしては、監視や障害対応に対する運用コストを飛躍的に削減できます。 また、パッチ当てやセキュリティのアップデートなどもRed Hat側が対応してくれるので、ユーザーはそのスケジュール（実行するタイミング）を決めるだけで済みます。 AWSサービスと連携しやすくなる ROSAは、最初からAWSの各種サービスとスムーズに連携できるよう設計されています。これによって、複雑なインフラ設定に時間を取られなくなるため、より迅速かつ安全にコンテナ基盤を構築・提供できるようになります。 Copyright © Red Hat, Inc. AWSのRoleとPolicyを利用したRed Hat側との連携 請求書の統合 ROSAの利用料金（OpenShiftのライセンス料やAWSのインフラ費用）は、すべてAWSの請求書に統合されて支払われます。 別個に契約や支払いを行う必要がないため、企業の購買手続きや予算管理の負担を大幅に軽減できるメリットがあります。   ROSAを使うことで、上記のように様々なメリットが得られますが、現在の標準アーキテクチャである「HCP（Hosted Control Planes）」の登場によって、更なるフルマネージドのサービスが利用可能になりました。 ここからは、コストや運用の楽さを劇的に向上させる「ROSA with HCP」について詳しく説明します。 ROSA with HCPとは ROSA with HCP ( Red Hat OpenShift Service on AWS with hosted control planes ) とは、簡単に言うとコントロールプレーンをRed Hat側のAWSに配置し、完全に管理を任せる仕組みです。 HCPが登場する前の従来の方式は、HCPと区別するために「ROSA Classic」と呼ばれていますが、以下の構成図を見ていただくと、一目でその違いが理解できると思います。 Copyright © Red Hat, Inc. ROSA Classicの構成図 Copyright © Red Hat, Inc. ROSA with HCPの構成図 構成図からもわかるように、Classic方式では、コントロールプレーンノードがユーザー自身のAWSアカウント（VPC）内に配置され、ワーカーノードと共存していました。 一方、HCP方式では、コントロールプレーンがユーザーのネットワーク環境から安全に分離された場所に配置され、AWS PrivateLinkを介してやり取りする仕組みになっています。 このような構成の違い以外にも、HCP方式は数多くのメリットを持っています。ここからは、どのようなメリットがあるか紹介します。 コントロールプレーンの管理コストの削減 コントロールプレーンには、APIサーバーやetcdデータベースなど、クラスター全体を制御する極めて重要なコンポーネントが含まれています。これらをRed Hat側が完全に管理・運用してくれるため、ユーザーの運用保守のコストが大幅に削減されます。 AWSインフラ費用（EC2代金）を節約できる 従来のClassic方式では、コントロールプレーンを構成するノード（EC2インスタンス）をユーザー自身のAWS環境内に作成する必要がありました。 OpenShiftの仕様上、クラスターの安定稼働（高可用性）を維持するためには最低3台のコントロールプレーンノードが必須となりますので、小規模な開発環境であっても、ベースとなるEC2の固定費用がどうしても高くなってしまうというコスト面の課題がありました。 HCP方式では、このコントロールプレーンがRed Hat側に完全に移動するので、ユーザーのAWSアカウントからは最低3台分のEC2の料金が完全に消えることになります。 これは、AWSのインフラコストを劇的に節約・削減できるというHCP方式だけの大きなメリットになります。 クラスター作成速度の向上 従来のClassic方式では、クラスターを新規作成するたびに、ユーザーのAWS環境内でコントロールプレーンのインフラも一から組み立てる必要がありました。そのため、クラスターが完全に起動して利用可能になるまでに、約30分〜40分ほどの待ち時間が発生していました。 HCP方式では、コントロールプレーンの構築・プロビジョニングがRed Hat側の環境で迅速に行われます。 ユーザーのAWS環境内では、アプリケーションを動かすためのワーカーノードのみを作成すれば良いため、クラスターの作成時間が約10分程度へと大幅に短縮されました。急ぎで新しい環境が必要になったりするビジネスシーンにおいて、このような時間の短縮は大きなメリットになります。 アップグレードの柔軟性 従来のClassic方式では、コントロールプレーンとワーカーノードのバージョンアップを密に連動させて管理する必要がありました。そのため、互換性の確認や影響範囲の調査を慎重に行わなければならず、事前の計画や検証に多くの工数を割く必要がありました。 HCP方式では、コントロールプレーンとワーカーノードの管理が完全に切り離されていますので、両者のアップグレードを別々のタイミングでスケジュールすることも可能です。 例えば、まずはRed Hat側が管理するコントロールプレーンだけを先行してアップデートし、アプリケーションが動くワーカーノードは業務影響の最も少ない別の日時に実施する、といった柔軟な運用ができるようになりました。   以上が、ROSA Classicと比べたHCP方式の特徴とメリットの解説になります。最後に、これまでご紹介した内容を表で簡単にまとめます。 ROSA ClassicとROSA HCPの比較表 比較項目 ROSA Classic（従来方式） ROSA with HCP（最新モデル） コントロールプレーンの配置 ユーザー自身のAWSアカウント Red Hat側 マスターノードのEC2費用 ユーザー負担 ユーザー側の負担ゼロ（Red Hat側で稼働するため） クラスター作成時間 約40分 約10分 アップグレード調整 両ノードが連動しているため、スケジュールの調整がしづらい 別々のタイミングで柔軟に調整・実行が可能 まとめ 以上、ROSAの概要から、現在の主流である「HCP（Hosted Control Planes）」の特徴と数々のメリットについてご紹介しました。 ROSA with HCPは、コスト・速度・運用のすべてにおいて優れており、現在のROSA構築におけるベストプラクティスとなっています。 これから新しくコンテナ基盤を検討される方に、この記事の内容が参考になれば幸いです。 次回は、実際にAWS上でROSA with HCPのクラスターを構築していく手順を詳しく解説します。ぜひ楽しみにしてください。 参考資料 AWS での Red Hat ソリューション Overview of responsibilities for ROSA ROSA HCP and ROSA classic Capability Matrix （ログイン必要） ROSA Best Practices and Recommendations Red Hat OpenShift Service on AWS 4 Introduction to ROSA ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post ROSA（Red Hat OpenShift Service on AWS）を利用したコンテナプラットフォーム構築 ~ROSAの特徴とメリット~ first appeared on SIOS Tech Lab .

こんな方へ特におすすめ セキュリティ対応において、何から手をつければいいか迷っている方 HSTSなどのセキュリティヘッダ導入が、他の環境（検証環境など）に与える影響を知りたい方 概要 こんにちは。サイオステクノロジーのはらちゃんです！ 今回はSL代表としてセキュリティスキャン対策のコミュニケーションチームに入りました。 そこで得た「現場でのリアルな立ち回り」「セキュリティ対応の基本となる考え方」「HSTS導入時の思わぬ落とし穴（副作用）」といった、実務に直結する知見をまとめていきます。 背景 ある日、内部的なセキュリティスキャンが実施され、レポートが提供されました。 結果は「外部から容易に利用されるサイトで、改善が必要な項目が多々ある」という厳しいものでした。 最終的に、各SLで担当者を立てて全社的に修正対応を図ることになりました。 対応前のマインドセット 実際の技術的な修正に入る前に、チーム全体で以下の「考え方のポイント」を共有しました。無駄な作業を減らすための非常に重要なステップです。 「廃止・退役できるリソースか？」を最初に問う これが最もコストがかからず、最も安全な究極のセキュリティ対策。 使っていない検証環境は、修正するのではなく消すのが正解。 「対応しない」なら客観的な根拠を システム上の都合でどうしても対応できない項目もある。 しかし、放置するのではなく「なぜ対応できないか（客観的に妥当な根拠）」を言語化し、ディスカッションのテーブルに上げることが求められる。 オープンなコミュニケーション 専用のSlackチャンネルを用意し、不明点や気づきはすぐに共有する体制を作成。 3つの対応ポイント 指摘事項は多岐にわたりましたが、大きく以下の3点に分類して対応を進めました。 1. OS・パッケージの脆弱性対応 対応 サポートされている最新版に遅滞なく更新する。 ツール Amazon Inspector + AWS Security Hub CSPM（EC2やECRのDockerイメージの脆弱性を可視化）。 2. 伝送経路（SSL / TLS）の修正 対応 TLS1.0 / 1.1などの古いプロトコル、脆弱な暗号スイート（cipher）を無効化する。 IE11対応などの特殊な要件がない限り、2026年現在では TLS 1.2 / TLS 1.3 中心 で問題なし。 ツール Mozilla SSL Configuration Generator で安全なconfigを作成し、 SSL Labs で評価を確認。 3. セキュリティヘッダの指定 対応 Webサーバー（またはCDN）にCSPやHSTSなどのヘッダを追加する。 ツール securityheaders.com でのチェック。 ここが一番の難所でした。特にCSP（Content Security Policy）は、設定を間違えると必要なJSやCSSが読み込まれずサイトが壊れるため、技術開発センターの管理下サイトで先行検証・適用を進めるという慎重なアプローチをとりました。 そして、私のSLに最も影響を与えたのが HSTS です。 課題 HSTSポリシーと「自己署名証明書」の衝突 HSTS（HTTP Strict Transport Security）は、ブラウザに対して「今後は絶対にHTTPSで接続しろ」と強制する強力なセキュリティヘッダです。 ベストプラクティスとしては、以下の指定が推奨されます。 max-age で1〜2年以上の長期間を指定 preload 指定 includeSubDomains 指定（サブドメインも全てHTTPS強制） ここで問題発生です。依頼事項として「 [社内検証用サブドメイン配下] でHTTP接続しているリソースはないか？」という確認がありました。最終的にSSL接続が必須になります。 私のSLでは、以下の社内検証環境が稼働していました。 OpenShift検証環境 自動構築で「自己署名証明書（オレオレ証明書）」を利用。 社内検証Rancher/GitLab環境 内部DNS設定で、 [社内検証用サブドメイン配下] を利用。 HSTSが引き起こす「副作用」 本番ドメインにHSTSの includeSubDomains が付与されると、それにアクセスしたブラウザはポリシーを記憶します。 その後、同じブラウザで社内検証環境にアクセスすると、ブラウザは「HTTPSでの接続」と「正当な証明書の提示」を厳格に要求します。 そうすると、検証環境で使っている自己署名証明書がブラウザに強固にブロックされ、アクセス不可になるという懸念が浮上したのです。 検討案 HSTSの副作用をどう回避するか？ 検証環境のために本番のセキュリティレベルを下げるわけにはいきません。私たちは以下の回避策を検討しました。 正規の証明書を自動発行する Let’s Encrypt (DNS-01認証): Route53と連携して証明書の取得・更新を全自動化する。 AWS Certificate Manager (ACM): AWS環境であれば、ACMで発行した証明書をALB等に割り当てるのが最もスマート。 社内検証・開発用ドメインを物理的に分ける 本番ドメインのサブドメインを使わず、検証専用の別ドメインを取得する。 GoogleやFacebookなどの大手テック企業も採用している王道のアプローチ。 再構築のタイミングでドメインを変更する（期間区切り） 「10月までは今の環境を使い、それ以降は新規作成する」という場合、次回の再構築時にドメイン構成を見直すというリスク受容の判断もアリ。 プライベートCAを構築する 社内用の認証局を立てる案だが、構築・維持のコストリスクが高いため優先度は低め。 まずは「影響を小さく検証」する 様々な理想論を挙げましたが、机上の空論で終わらせず、まずは「実際のブラウザ挙動」を確かめるスモールスタートを切ることにしました。 【決定したネクストアクション】 技術管理担当者が、 sios.jp に HSTS ポリシー（ includeSubDomains あり）を適用する。 Slackで連絡を受けたら、インフラ担当者がブラウザで sios.jp にアクセスし、HSTSポリシーを学習させる。 そのまま検証環境へアクセスし、HTTPS強制ブロックの挙動を確認する。 回避策の検証 HSTSポリシーを共有しない「シークレットモード」や「別プロファイルのブラウザ」を利用することで、自己署名証明書の検証環境へアクセス可能か（業務への影響を回避できるか）をテストする。 まとめ セキュリティスキャンからの指摘は、一見すると「ただの面倒な作業」に思えるかもしれません。 しかし、今回のように「なぜHSTSのサブドメイン指定が検証環境を壊すのか？」「どうやって回避するのか？」をチームで議論することで、インフラ設計の解像度がグッと上がります。 不要なリソースは捨てるのが最強のセキュリティ。 HSTS導入時は、サブドメインで動いている検証環境（自己署名証明書）の死に直結しないか注意する。 理想のアーキテクチャ（ドメイン分離やACM活用）を描きつつも、まずはプライベートブラウザ等の運用回避で業務を止めない立ち回りも重要。 今後も、こうした全社的な取り組みを通して得られた知見を、皆さんに共有していきたいと思います！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post セキュリティスキャン指摘対応 | HSTS導入の影響と回避策 first appeared on SIOS Tech Lab .