三流エンジニアの落書き帳

さあ、今日も未知という扉を開けてみよう

OCIの勉強メモ～IAM編～

最近OCIの勉強を始めたので、個人的なメモをブログに残しておきます。

第1回目はIAMです。

AuthNとAuthZ

AuthN(認証)はアクセスしようとしているユーザーが本当にその人なのか確認するプロセス

AuthZ(認可)はそのユーザーにどの操作を許可するのか決定するプロセス

OCIの認証方式

  • パスワード認証
    • IAMユーザーがOCIにログインするときに、ユーザー名とパスワードを入力してログインする
    • MFA認証を利用することも可能
  • API署名キー
    • リソースプリンシパルがその他のサービスにアクセスするときに利用
  • 認証トークン
    • 一時的なアクセスを許可したいときに

OCI概念・用語

コンパートメント

コンパートメントを利用することで、OCI上のリソースを論理的なグループに分けることが可能

アクセスコントロールを考慮して、コンパートメントを適切に設計する必要がある

OCIアカウントを作成するとテナント(ルート・コンパートメント)が作成される

ユーザーはテナントの直下にコンパートメントを設計していく

コンパートメントの特徴

  • リソースは必ず1つのコンパートメントに含まれる
  • リソースを同時に複数のコンパートメントに含めることはできない
  • 一部のリソースを除いて、リソースが属するコンパートメントを変更することができる
  • 異なるリージョンにあるリソースでも、同じコンパートメントに含むことができる（コンパートメントは論理的なグループである）
  • コンパートメントごとに、作成できるリソースの上限を設けることができる（費用のコントロールが可能）
  • コンパートメントは入れ子にすることができる（テナントを除き最大6階層まで作成可能）
  • 親コンパートメントにアタッチしたポリシーは、その子コンパートメントにも適用される(ポリシーの継承)

プリンシパル

OCI上でアクションを起こす主体で、次の2種類に分けることができる

グループ

OCIではIAMユーザーに直接権限を付与することができない

権限を付与する場合、IAMユーザーを何かしらのグループに含めたうえで、グループに権限を付与する

ポリシー

OCIでは「何に対して」、「どの操作を」許可するか決める権限を、ポリシー・ステートメントで記述する。

基本的な文法は下記の通り

Allow <Subject> to <Verb> <Resource-Type> in <Placement> <where Condition>

例えば下記ポリシーはOCIアカウントを作成すると、自動で作成されるポリシーである

Allow group Administrators to manage all-resources in tenancy

これはいわゆるルートユーザーを実現するためのポリシーである

Subject

ポリシーの「何に対して」の何に、あたる部分

ここにはグループ名を記述する

グループ名を指定する方法は、グループ名そのものを記述する方法と、グループ名を表すOCIDを記述する方法がある

以下に例を挙げる

Allow group <group-name> グループ名を指定する
Allow group id <OCID> OCIDでグループを指定する
Allow any-user 任意のグループに対するポリシーであればany-userを指定する

任意のグループに対するポリシーの場合、グループ名ではなくany-userという特別な記述をする

Verb

ポリシーの「どの操作を」にあたる部分

以下の4種類があり、下に行くほど権限が強くなる

  • inspect
    • リソースの一覧をリストする
    • 主な対象者は外部監査人
  • read
    • inspect + ユーザー指定のメタデータや実際のリソースの参照権限
    • 主な対象人は内部監査人
  • use
    • read + 既存のリソースの操作権限*1
    • 主な対象人は通常ユーザー
  • manage
    • リソースに関するすべての権限
    • 主な対象人はシステム管理者

Permission

verbは、内部的には事前定義されたpermissionの集合体として定義されている

そしてpermission自体は、リソースに対する最小の操作権限として定義される

またOCI上の各API操作に対して、必要なpermissionが定義されている

例えばvolumeリソースタイプに対して、ボリュームの一覧をリストするAPIであるListVolumesをコールするために必要なpermissionはVOLUME_INSPECTである

そして、inspectを付与すれば、VOLUME_INSPECT permissionが付与されて、ListVolumes APIをコールできる

Resouce-Type

操作の対象となるリソースで大きく分けて2種類に分類できる

  • 集合リソース・タイプ　いくつかのリソースが集約されたもの
  • 個別リソース・タイプ　個別のリソース

集合リソース・タイプは様々だが、以下に例を挙げる

  • instance-family
  • virtual-network-family
  • volume-family

なお、任意のリソースに対する権限を付与したい場合はall-resoucesを指定する

すべての集合リソース・タイプは下記リンクから確認できる

https://docs.oracle.com/ja-jp/iaas/Content/Identity/Reference/policyreference.htm#Resource

Placement

Placementにはポリシーが適用されるコンパートメントを指定する

例として、Aというコンピュートに適用されるポリシーであればin compartment Aと記述する

前述した通り、コンパートメントにアタッチされたポリシーは、その子や孫コンパートメントにも継承される

ここで、

tenancy > A > B > C

という階層でコンパートメントが設計されているとする

この時、Aにアタッチされたポリシーは、BとCにも適用される

また、Aにアタッチはするがポリシーの適用範囲をBとしたいときは、in Bと記述すればよい（直下のコンパートメントであれば直接記述できる）

ただし、アタッチ対象をAとし、ポリシーの適用範囲をCのように階層が直接つながっていないケースではin B:Cのように：でつなげる必要があるため注意が必要

where句

where句に条件を記述することで、さらに細かい権限付与が可能となる

使用できる条件演算子は次の通り

=
!=(ノットイコール)
or
and
any(複数の条件のうち、1つでも真なら真を返す)
all(複数の条件すべてが真なら真を返す)

またwhere句には、以下の2種類の変数が指定できる

  • request
    • 実行するAPI操作そのものを条件にする場合
    • 例) request.operation 許可するAPI操作名を指定する
  • target
    • 操作対象となるリソースを条件にする場合
    • 例) target.group.name 操作対象グループ名を指定する

すべてのリソース・タイプで、利用できる一般的な変数は下記リンクから確認できる

docs.oracle.com

リソース・タイプごとに利用できる変数一覧は下記リンクから確認できる

docs.oracle.com

where句を使ったポリシーの例を見てみよう

Allow group Dev1 to manage all-resources in tenancy
where any {
  request.operation = 'ListVolumes'
  request.operation = 'GetVolumes'
}

まずこのポリシーの1行目は、Dev1というグループにテナンシ内のすべてのリソースにmanage権限を付与している

このままだと非常に強い権限だが、where句を見ると操作できる操作がListVolumesもしくはGetVolumesだけだと分かる

このように条件付きのポリシーを記述することで、きめ細かいポリシーを実現できる

共通ポリシー

OCIには一般的なタスクを実現するために必要なIAMポリシーが用意されている

docs.oracle.com

上記リンクには「ネットワーク管理者によるクラウド・ネットワークの管理」を行うためには、次のIAMポリシーを適用させるとある。

Allow group NetworkAdmins to manage virtual-network-family in tenancy

共通ポリシーはあくまでも一般的なタスクを実現するためのポリシーであり、詳細な要件は企業によって様々である

実現したい内容に近い共通ポリシーを見つけ、そこからさらに要件に合ったポリシーに変更していくといった作業が必要である

動的グループ(Dynamic Groups)

IAMユーザーの集合としてのグループではなく、インフラストラクチャのグループ

動的グループは、メンバーをグループに明示的に追加するのではなく、予め定義したマッチングルールに合致したメンバーが追加される

動的グループにIAMポリシーを適用することで、動的グループに含まれるリソース・プリンシパルは他のOCIサービスに対してAPIを実行できる

例えば特定のコンパートメントに属するコンピュートインスタンスを、含める動的グループは次のようになる

All { resource.type = 'instance' resource.compartment.id = '<コンパートメントのOCID>' }

また、動的グループにポリシーを適用させる場合、groupではなくdynamic-groupと指定する

Allow dynamic-group groupA to ~

ネットワークソース

ネットワークソースによって、IPアドレスやVCNによるアクセス元の制御を行うことができる

ネットワークソースを作成したうえで、条件付きポリシー内で利用することができる

例えばnwr01というネットワークソースを作成した後に、次のようなポリシーを作成できる

Allow group Dev1 to manage volume-family in tenancy where request.networkSource.name = 'nwr01'

Identity Domains

OCIの認証基盤は元々OCI IAMとIDCS(Identity Cloud Service)の2つが存在していた

これら2つの認証基盤にはそれぞれ以下のような特徴がある

  • OCI IAM
    • OCIのリソースに対してアクセス権を制御する仕組み
    • IAMユーザーやグループといったOCI上のID管理
    • 無償で利用できる
  • IDCS
    • IDaaSにカテゴライズされる統合認証基盤のサービス
    • クラウドサービスだけでなくオンプレミスのアプリケーションに対する認証連携を実現できる
    • SSO、MFA、ソーシャル・ログインなどが利用できる
    • 高機能だが有償

これら2つはログイン方法や、パスワード管理が異なり同時に運用するのは難しかった

アイデンティティ・ドメインはこれら2つの認証基盤を統合させた、新たな認証基盤である

つまり、

OCI IAM Identity Domains = OCI IAM + IDCS

Identity Domainsの特徴

  • テナンシー作成時に必ず1つのDefault Identity Domainがルート・コンパートメントに作成される
  • テナンシーには複数のIdentity Domainsを持つことが可能
  • 5つの課金タイプがある
    • Free
    • Oracle Apps
    • Oracle Apps Premium
    • Premium
    • External User

Freeは無償で利用可能、一番高価なPremiumは機能制限が無い

参考：

https://speakerdeck.com/oracle4engineer/overview-oci-iam-identity-domains

まとめ

第1回はIAMについて勉強しました。

当たり前ですが、AWSと似ているところ、異なるところがあり面白いですね。

*1:詳細はリソースタイプに依存するため、ドキュメントを参照するのが良い