この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Service Catalogには「制約」と呼ばれる設定がいくつかあるのですが、ドキュメントだけ読んでいても具体的な機能がイメージできなかったので整理してみました。
ざっくり制約のユースケース
各制約を触ってみて、どんな時に使う制約なのかを簡単にまとめました。あくまで私が触った感想です。
- 起動制約
- エンドユーザーに与えた権限以上のことを製品の起動で行いたい場合
- 通知の制約
- 製品起動時のCFnスタックイベントを全て通知させたい場合
- タグ更新の制約
- エンドユーザーにプロビジョニング済み製品のタグ管理を自由に行わせたい場合
- スタックセットの制約
- １つの製品をアカウント・リージョン単位に展開したい場合、または制御したい場合
- テンプレート制約
- 製品の起動時に入力するパラメータに制限をかけたい場合
Service Catalogにおける制約とは
Service Catalogにおける制約とは、設定した製品単位に適用されるルールのことです。
エンドユーザーがポートフォリオ内にある製品を起動する時に、適用されている「制約」に沿う形で製品を起動・管理することになります。
各制約について
それではService Catalogで利用できる制約についてみていきましょう。利用できる制約は以下の５つです。
- 起動制約
- 通知の制約
- タグ更新の制約
- スタックセットの制約
- テンプレート制約
1. 起動制約
起動制約はエンドユーザーが製品を起動する時に、どのIAMロールの権限を利用して起動するのかを指定する制約です。もっと具体的に言えば、「製品を起動する時にService Catalogが引き受けるIAMロールの指定」となります。
エンドユーザーの権限に許可を与えたくないが、製品を起動させたいケースで活躍する制約です。起動制約により製品の起動はIAMロールを引き受けて実行されるため、エンドユーザーは製品の中で実行される権限を持つ必要はなくなります。
IAMロールの指定は、コンソールからは「プルダウンで選択」・「ARNを入力」・「ロール名を入力」の３パターンがあります。基本プルダウンから選択でいいですが、ポートフォリオを共有して複数アカウントで利用する以下のようなケースでロール名を入力する必要があったりします。
【Service Catalog】組織内にポートフォリオを共有してメンバーアカウントから製品を起動してみた | DevelopersIO
起動制約を設定しない場合は、製品を起動したユーザーの権限を使用します。製品の起動に必要な権限については以下ドキュメントを参照してください。
AWS Service Catalog の Identity and Access Management - AWS Service Catalog
2. 通知の制約
通知の制約は、製品の起動で作成されるCloudFormationスタックに通知を設定する制約です。この制約を適用すると、CloudFormationのスタックイベントをSNS経由で通知できます。
SNSトピックを指定して通知先を設定します。このコンソール上でSNSトピックを新規作成できますが、サブスクリプションまでは作成できないので注意しましょう。
この制約は、実体としてはCloudFormationの通知オプションに指定したSNSトピックの自動設定です。スタックイベントが全て通知されるので、テンプレートの規模によってはすごい量の通知になるので注意しましょう。
3. タグ更新の制約
タグの更新の制約を使用すると、プロビジョニング済み製品のタグ更新をエンドユーザーに許可または禁止できます。
製品を起動する際、展開されるリソースに対して独自のタグをつけることができるのですが、ここの値の変更を製品起動後に変更を許可・禁止できるのがタグ更新の制約です。
製品の起動時にキー:env、値:devとしてタグを追加した製品に変更できるか試してみます。
制約を設定しないで製品の変更画面を見ると、プロビジョニング済み製品のタグを変更できません。(このようにタグの設定部分が表示されなくなる)
次にタグ更新を許可した制約を設定してみます。以下のようにタグ更新の制約で許可を与えます。
プロビジョニング済みの製品から、先ほど起動した製品の更新画面を開いてみます。すると、タグの更新部分が表示されるようになりました。
このようにエンドユーザーに対して、起動後にもタグの更新を制御するのがタグ更新の制約です。コスト管理やアクセス管理でタグを厳密に制御している場合は、許可しないのが良いかと思います。
4. スタックセットの制約
スタックセットの制約は、通常CloudFormationでスタックを作成するところをStackSetsで展開する制約です。この制約では、対象のアカウントやリージョンに制限をかけることが可能です。
対象とできるアカウント・リージョンについては制約を作成する時に入力します。またStackSetsを利用する時と同様にIAMロールの指定などもここで行います。
スタックセットの制約を設定した製品を起動すると、制約作成時に入力したアカウントやリージョンの中から展開する先を選択できます。
製品を利用するアカウント、リージョンが決まっている場合は用途がありそうですね。
5. テンプレート制約
テンプレート制約は製品を起動する際に、入力されるパラメータに条件を追加できる制約です。
例えば、エンドユーザーにEC2インスタンスを作成する製品を利用させたいが、大きなインスタンスタイプは使わせたくないケースで活躍します。
- 制約なし：入力パラメータにインスタンスタイプを自由に入力可
- 制約あり：特定のインスタンスタイプは起動時にエラーとする
試しにS3バケットを作成するテンプレートで、バケット名service-catalog-constraintsを条件とするテンプレート制約を設定してみました。
{
"Rules": {
"s3BucketName": {
"Assertions": [
{
"Assert": {
"Fn::Contains": [
[
"service-catalog-constraints"
],
{
"Ref": "BucketName"
}
]
},
"AssertDescription": "Allow only `service-catalog-constraints` for S3 bucket name"
}
]
}
}
}※ルールの書き方についてはテンプレート制約のルール - AWS Service Catalogを参照してください。
製品を起動する時のバケット名に許可されていない値を入力すると、すぐにエラーメッセージを表示してくれました。AssertDescriptionで設定したメッセージを表示してくれる点も分かりやすくて嬉しい。
テンプレート制約はルールの書き方を理解する必要がありますが、エンドユーザーのミスを防げるため是非利用していきたい制約ですね。
まとめ
５つの制約について触りながらまとめてみました。改めてそれぞれの制約について整理してみます。
- 起動制約(よく使いそう)
- 製品を起動する時に、どのIAMロールの権限を利用するかを制御する制約
- 通知の制約(あまり利用しないかも)
- CFnスタックイベントの通知設定を強制する制約
- タグ更新の制約(一部の環境では有用そう)
- プロビジョニング済み製品のタグ変更を許可・制限する制約
- スタックセットの制約(一部の環境では有用そう)
- StackSetsの機能で指定した複数アカウント・リージョンに制限する制約
- テンプレート制約(よく使いそう)
- CloudFormationテンプレートの入力パラメータを制御する制約
特にテンプレート制約は、活用方法によっては便利そうだなと感じました。Service Catalogを触り始めた方の参考になれば幸いです。
2
