はじめに
-
やっとROSA(Red Hat OpenShift Service on AWS)がGAされました。 - AWSのブログに以下文言がありましたが、OpenShiftが実家になりつつある人々にはGood newsなのです。
we are continually thinking about how we can make them feel at home on AWS.
- 尚、以降の手順等はかなり適当に実行しているので、誤りやセキュリティ的な問題を抱えているものがあると思います。悪しからず。
ROSAとは
- 詳細は、AWSのサイト、若しくは、Red Hatのサイトを参照しましょう。
- 有り体に言えば、OpenShiftのControl PlaneやData Planeの運用・管理をAWSやRed HatのSREチームと共有できるサービスと理解しています。
- 既にARO(Azure)やROKS(IBM Cloud)といった、Managed OpenShiftは世の中に出ており、ROSA(AWS)もこれらと同等のサービスなのでしょう。
ROSAのドキュメント
-
前提条件
- クラスタ作成に必要なIAM、SCP権限、アクセス要件、セキュリティ要件などが記載されています。
-
クイックスタート
- クイックスタートを含む、ROSAのドキュメントリソースが詰まっていました。
-
役割分担
- Red Hat・AWSと利用者の役割分担のマトリクスが記載されています。
ROSAの前提条件
当該ページにはいくつか重要なことが記載されています。
- ROSAのクラスターは、AWS Organizationのサブアカウント上でホストすることを推奨している
- サブアカウントにはSCPが適用できるので、サブアカウント内で扱えるアクセスを許可を制限できるから(Red HatのSREチームのアクティビティを制限できるから)
- Red HatのSREチームは、SCPを制御することはできない
- ROSAのクラスターを管理するために必要なアクセス許可(
AdministratorAccess
)をRedHatに与える
お、おう。(汗
きっと、役割分担の話なのだろうけど、利用者は真面目にPolicy切らないと、いろんなリスクシナリオが出来上がっちゃいそうな気がするのです。規約みたいなものがあるのかな。
利用者側の前提条件
利用者側の前提条件が記載されています。(自分の理解を書いたので、誤りがあるかも)
-
Account
- ROSAをサポートするのに十分なリソースが確保できる。
- ROSAをデプロイするAWSアカウントはSCPが適用されたAWS Organizationに属している必要がある。
- OrganizationやSCPは必須ではないけど、後述にリストされているすべてのアクションを実行できる権限を持っている。
- AWSアカウントをRedHatに譲渡するような構成にしない。
- SREチームの活動に対し、使用制限を課すことはできない。制限を課すと著しくサービスレベルが下がるため。
-
Access requirements
- ROSAを適切に管理するには、RedHatがAdministratorAccessが適用された管理者ロールを持つ必要がある。
- Red Hatは、AWSコンソールへのアクセスが必要となる。このアクセスは、RedHatによって保護および管理されている。
- 利用者は、パーミッションを昇格させるためにROSA内でAWSアカウントを利用してはいけない。
- (ちょっと意味がわからない。文字通りAWSアカウントの強い権限の行使が駄目なのか、Assume Roleが駄目なのか、SecretにAccess KeyやSecretを持つのが駄目なのか?)
- ROSA CLI、または、OCMはAWSアカウントで直接実行してはいけない。
-
Support requirements
- AWSのBusiness Supportに入ることを推奨とする。
- Red Hatは、利用者に代わってAWS Supportをリクエストする権限を持つ。
- Red Hatは、利用者に代わってAWSの上限緩和申請をリクエストする権限を持つ。
- Red Hatは、特に指定されていない限り、AWSクラスター上のすべてのROSAを同じ方法で管理する。
-
Security requirements
- ボリュームのスナップショットは、利用者が指定したAWSアカウント内、リージョン内に残る。
- Red Hatは、許可されたIPアドレスからEC2、及び、APIへのアクセス権を持っている必要がある。
- システムログと監査ログをRedHatが管理するログスタックに転送するアクセスが許可されている必要がある。
かなり強い権限、接点をRed HatのSREチームに許可しないといけないようです。
利用者側の必要な手順
続いて、利用者側での手順です。
AWS Organization管理下の既存、または、新規のAWSアカウントを用意する
AWS Organizationのドキュメントを参照しながら作成します。
Red Hatが必要なアクションを実行できるようにするために、SCPを作成する
SCPのドキュメントを参照しながら作成します。
適用するポリシーは以下の通りです。ガバガバだなあ、どこまで制限していいのだろう。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"autoscaling:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"elasticloadbalancing:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"events:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"logs:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"support:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"kms:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"sts:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"tag:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"route53:*"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"servicequotas:ListServices",
"servicequotas:GetRequestedServiceQuotaChange",
"servicequotas:GetServiceQuota",
"servicequotas:RequestServiceQuotaIncrease",
"servicequotas:ListServiceQuotas"
],
"Resource": [
"*"
]
}
]
}
SCPをAWSアカウントに紐付ける
AWS Organization → アカウント → 作成したアカウントを選択します。
さらに、画面右部に表示されるメニューより、サービスコントロールポリシーを選択します。
そこで、先程作成したSCPをアタッチします。(Full-Accessはデタッチ必要?必要そうな気がする。)
Red Hatが使うIAM User
Red Hatは、以下のIAM Policy、IAM User、IAM Roleを作成し、管理をするとのことです。
- IAM Policy
-
AdministratorAccess
を利用
-
- IAM User
-
osdManagedAdmin
を利用(勝手に作成される)
-
ROSAが作成するAWSリソース
ROSAの構成の概要は以下の通り。
結構派手に使いますね~。普段、ローカルでOpenShift動かしてヾ(´∀`)ノキャッキャしてる勢には辛い。
- EC2
- Three m5.xlarge minimum (control plane nodes)
- Two m5.xlarge minimum (infrastructure nodes)
- Two m5.xlarge minimum but highly variable (worker nodes)
- EBS
- Control Plane Volume
- Size: 350GB
- Type: io1
- Input/Output Operations Per Second: 1000
- Infrastructure Volume
- Size: 300GB
- Type: gp2
- Input/Output Operations Per Second: 100
- Worker Volume
- Size: 300GB
- Type: gp2
- Input/Output Operations Per Second: 100
- Control Plane Volume
- ELB
- NLBが2つ(API用)、ELBが最大2つ(アプリ用)
- S3
- EBSのスナップショット用に使う
- VPC
- 1つのクラスタに対し、1VPC
- Subnet
- 1つのAZの場合は2つのSubnet。複数のAZの場合は6つのSubnet。
- Router tables
- PrivateのSubnet毎に、1つのRoute Table。更に1つのクラスタ毎に1つの追加のRoute Table。
- Internet gateways
- 1つのクラスタ毎に1つのIGW。
- NAT gateways
- PublicのSubnet毎に1つのNAT Gateway。
- Security groups
環境のセットアップ
環境のセットアップをする。
Red Hat アカウントを作成する
ROSAのインストールに必要とのことです。アカウント作成手順は省略します(既に持っているので)。
アカウント作成後はこちらのURLからトークンを取得できます。
ROSAを有効化する
Organizationで作成したAWSアカウントのROSAにアクセスし、Enable OpenShiftをクリックします。
有効化後は以下の表示になります。
AWS CLIをセットアップする
CloudShell上でAWS CLIをセットアップしていきます。ドキュメントはこちらを参照のこと。
ただ、ここで使用するIAM Userに紐づくIAM Policyなどの指示が無い気がします。ここでは適当にAdministratorAccess
を持つIAM Userを利用することとします。
$ aws configure
AWS Access Key ID [None]: ...snip...
AWS Secret Access Key [None]: ...snip...
Default region name [None]: ap-northeast-1
Default output format [None]: json
$ aws sts get-caller-identity
{
"UserId": "...snip...",
"Account": "...snip...",
"Arn": "arn:aws:iam::...snip...:user/rosaCli"
}
ROSA CLIをインストールする
curlでダウンロードして、展開する。
$ curl -OL https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/rosa/latest/rosa-linux.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 14.8M 100 14.8M 0 0 2350k 0 0:00:06 0:00:06 --:--:-- 3284k
$ sudo tar -zxvf rosa-linux.tar.gz -C /usr/local/bin/
rosa
$ rosa
Command line tool for Red Hat OpenShift Service on AWS.
Usage:
rosa [command]
Available Commands:
completion Generates bash completion scripts
create Create a resource from stdin
...snip...
前提条件等の確認
十分な権限を持っているかを確認します。
$ rosa verify permissions
I: Validating SCP policies...
I: AWS SCP policies ok
十分なサービスクオータがあるかを確認します。
$ rosa verify quota --region=ap-northeast-1
I: Validating AWS quota...
E: Insufficient AWS quotas
E: Service ec2 quota code L-1216C47A Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances not valid, expected quota of at least 100, but got 5
EC2インスタンスのクオータ設定が少なすぎるようでした...。
上限緩和申請後に、リトライします。
$ rosa verify quota --region=ap-northeast-1
I: Validating AWS quota...
I: AWS quota ok
rosaコマンドでログインします。ここのトークンは先程Red Hatのサイトから取得したものを使います。
$ rosa login --token="\
eyJ ...snip..."
I: Logged in as 'rh-rosa-user' on 'https://api.openshift.com'
Red HatとAWSの認証情報がセットアップされていることを確認します。
$ rosa whoami
AWS Account ID: ...snip...
AWS Default Region: ap-northeast-1
AWS ARN: arn:aws:iam::...snip...:user/rosaCli
OCM API: https://api.openshift.com
OCM Account ID: ...snip...
OCM Account Name: ...snip...
OCM Account Username: 1ksen
OCM Account Email: ...snip...@...snip...
OCM Organization ID: ...snip...
OCM Organization Name: ...snip...
OCM Organization External ID: ...snip...
良い感じですね。
初期化処理
ここまでで、準備は一通り完了です。いざ、初期化処理の実行へ。
$ rosa init
I: Logged in as '1ksen' on 'https://api.openshift.com'
I: Validating AWS credentials...
I: AWS credentials are valid!
I: Validating SCP policies...
I: AWS SCP policies ok
I: Validating AWS quota...
I: AWS quota ok
I: Ensuring cluster administrator user 'osdCcsAdmin'...
I: Admin user 'osdCcsAdmin' created successfully!
I: Validating SCP policies for 'osdCcsAdmin'...
I: AWS SCP policies ok
I: Validating cluster creation...
I: Cluster creation valid
I: Verifying whether OpenShift command-line tool is available...
W: OpenShift command-line tool is not installed.
Run 'rosa download oc' to download the latest version, then add it to your PATH.
このrosa init
の処理では、CloudFormationのテンプレートが実行されているとのこと。
一応内容を確認しますが、rosa whoami
で、ap-northeast-1を指定しているのに、CFnのStackはus-east-1で作成されていました。
IAMに関するStackって、ap-northeast-1からでも作れなかったっけ。まあ、いっか。
内容自体はAdministratorAccess
のPolicyを要求するosdCcsAdmin
というIAM Userが作成されています。(IAM User)
$ aws cloudformation describe-stacks --region us-east-1
{
"Stacks": [
{
"StackId": "arn:aws:cloudformation:us-east-1:...snip...:stack/osdCcsAdminIAMUser/...snip...",
"StackName": "osdCcsAdminIAMUser",
"CreationTime": "...snip...",
"RollbackConfiguration": {},
"StackStatus": "CREATE_COMPLETE",
"DisableRollback": false,
"NotificationARNs": [],
"Capabilities": [
"CAPABILITY_IAM",
"CAPABILITY_NAMED_IAM"
],
"Tags": [],
"DriftInformation": {
"StackDriftStatus": "NOT_CHECKED"
}
}
]
}
$ aws cloudformation get-template --stack-name osdCcsAdminIAMUser --region us-east-1
{
"TemplateBody": {
"Resources": {
"osdCcsAdmin": {
"Type": "AWS::IAM::User",
"Properties": {
"ManagedPolicyArns": [
"arn:aws:iam::aws:policy/AdministratorAccess"
],
"UserName": "osdCcsAdmin"
}
}
}
},
"StagesAvailable": [
"Original",
"Processed"
]
}
ocコマンドのセットアップ
rosaコマンドからダウンロードできるようです。
$ rosa download oc
I: Verifying whether OpenShift command-line tool is available...
W: OpenShift command-line tool is not installed.
Run 'rosa download oc' to download the latest version, then add it to your PATH.
I: Downloading https://mirror.openshift.com/pub/openshift-v4/clients/ocp/latest/openshift-client-linux.tar.gz
Downloading... 24 MB complete
I: Successfully downloaded openshift-client-linux.tar.gz
$ ls
openshift-client-linux.tar.gz rosa-linux.tar.gz
$ sudo tar zxvf openshift-client-linux.tar.gz -C /usr/local/bin/
README.md
oc
kubectl
$ rosa verify oc
I: Verifying whether OpenShift command-line tool is available...
I: Current OpenShift Client Version: 4.7.3
ROSA Clusterの作成
クラスタを作成します。
※ドキュメントの例では15文字以上のcluster-nameを指定しているのに、実際は通らないです。
$ rosa create cluster --cluster-name=rosa-poc-cluster1
E: Cluster name must consist of no more than 15 lowercase alphanumeric characters or '-', start with a letter, and end with an alphanumeric character.
$ rosa create cluster --cluster-name=rosa-poc-1
I: Creating cluster 'rosa-poc-1'
I: To view a list of clusters and their status, run 'rosa list clusters'
I: Cluster 'rosa-poc-1' has been created.
I: Once the cluster is installed you will need to add an Identity Provider before you can login into the cluster. See 'rosa create idp --help' for more information.
I: To determine when your cluster is Ready, run 'rosa describe cluster -c rosa-poc-1'.
I: To watch your cluster installation logs, run 'rosa logs install -c rosa-poc-1 --watch'.
Name: rosa-poc-1
ID: ...snip...
External ID:
OpenShift Version:
Channel Group: stable
DNS: rosa-poc-1....snip....openshiftapps.com
AWS Account: ...snip...
API URL:
Console URL:
Region: ap-northeast-1
Multi-AZ: false
Nodes:
- Master: 3
- Infra: 2
- Compute: 2 (m5.xlarge)
Network:
- Service CIDR: 172.30.0.0/16
- Machine CIDR: 10.0.0.0/16
- Pod CIDR: 10.128.0.0/14
- Host Prefix: /23
State: pending (Preparing account)
Private: No
Created: ...snip...
Details Page: https://cloud.redhat.com/openshift/details/...snip...
尚、オプション指定せずに実行すると、Single-AZの構成となるみたいです。
オプションは多く受け付けられるようになっており、本番向けには設計しないとですね。
$ rosa create cluster --help
Create cluster.
Usage:
rosa create cluster [flags]
Examples:
# Create a cluster named "mycluster"
rosa create cluster --cluster-name=mycluster
# Create a cluster in the us-east-2 region
rosa create cluster --cluster-name=mycluster --region=us-east-2
Flags:
-c, --cluster-name string Name of the cluster. This will be used when generating a sub-domain for your cluster on openshiftapps.com.
...snip...
クラスタの構築には40分程度かかるみたい。
rosa describe cluster
コマンドで確認できます。
※ドキュメントには-c
のオプション記載が無いが、実際は必要でした。
$ rosa describe cluster -c rosa-poc-1
Name: rosa-poc-1
ID: ...snip...
External ID: ...snip...
OpenShift Version:
Channel Group: stable
DNS: rosa-poc-1....snip....openshiftapps.com
AWS Account: ...snip...
API URL:
Console URL:
Region: ap-northeast-1
Multi-AZ: false
Nodes:
- Master: 3
- Infra: 2
- Compute: 2 (m5.xlarge)
Network:
- Service CIDR: 172.30.0.0/16
- Machine CIDR: 10.0.0.0/16
- Pod CIDR: 10.128.0.0/14
- Host Prefix: /23
State: installing
Private: No
Created: ...snip...
Details Page: https://cloud.redhat.com/openshift/details/...snip...
ふと、us-east-1のEC2インスタンスを見たところ、クラスタ作成時に何かが作られた形跡があります。bootstrap的な何かなんだろうけど、特定リージョンしか許可されていないOrganization Unitなら悲しい気持ちになりそう😖
$ aws ec2 describe-instances --region us-east-1
{
"Reservations": [
{
"Groups": [],
"Instances": [
{
"AmiLaunchIndex": 0,
"ImageId": "ami-000db10762d0c4c05",
...snip...
ROSA Clusterへのアクセス
40分後、再度rosa describe cluster
コマンドで確認します。
$ rosa describe cluster -c rosa-poc-1 | grep State:
State: ready
rosa create admin
コマンドで、ログインパスワードの払い出しをします。
尚、この手順の実行前にIdPやLDAPとの統合をおすすめされています。真面目に作るときは適用しましょう。
$ rosa create admin -c rosa-poc-1
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 'rosa-poc-1'.
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.rosa-poc-1....snip....openshiftapps.com:6443 --username cluster-admin --password ...snip...
I: It may take up to a minute for the account to become active.
oc login
します。
$ oc login https://api.rosa-poc-1....snip....openshiftapps.com:6443 --username cluster-admin --password ...snip...
$ oc whoami
cluster-admin
Web Consoleへもアクセスしてみます。
$ rosa describe cluster -c rosa-poc-1 | grep Console
Console URL: https://console-openshift-console.apps.rosa-poc-1.xcfa.p1.openshiftapps.com
ブラウザでアクセスすると、以下の通り。SREチームもここから入ってくるのね。
先程のrosa create admin
で作成されたcluster-admin
でログインします。
なんとかなったね😆
ROSA Clusterの削除
個人でお試しするにはお財布に厳しいのでrosa delete cluster
コマンド、rosa init
コマンドで削除します。グッバイ👋
$ rosa delete cluster --cluster=rosa-poc-1 --watch
? Are you sure you want to delete cluster rosa-poc-1? Yes
I: Cluster 'rosa-poc-1' will start uninstalling now
W: Logs for cluster 'rosa-poc-1' are not available
...snip...
$ rosa init --delete-stack
I: Logged in as '1ksen' on 'https://api.openshift.com'
I: Validating AWS credentials...
I: AWS credentials are valid!
I: Deleting cluster administrator user 'osdCcsAdmin'...
I: Admin user 'osdCcsAdmin' deleted successfully!
ROSAがGAされました
また、時間あるときに触ってみよう。以下はメモです。
- 簡単にOpenShiftのクラスタのセットアップが可能。しかもRed HatのSREチームが面倒を見てくれるし、on EC2より安い!
- 組織のポリシーと設計を踏まえた事前の仕込み(SCPの折り合い、`rosa create clusterの引数)が非常に大変そう。
- 恐らく、事前の仕込みを捗らせるには、役割分担の理解が重要になりそう。
- ROSAが持っている権限を用いるアプリケーションアーキテクチャの場合、SREの権限でs3覗けたり、鍵消せたりしちゃう気がするのだけど、このへんのPolicy設計どうするのだろう。
おしまい。