IBM Cloud IAM をざっくり把握する

IAMは、セキュリティを維持しながら多人数で、役割りを分担して、クラウドを運用するために必要とされる、個人やコードの識別とアクセス管理のための機能です。

SoftLayer や Bluemix のブランド名で提供されている時代から断片的に存在していましたが、2017年9月から統合的なIAMが導入され、現在の主要なサービスはIAM対応となっています。


#### 参考資料
[Introducing IBM Cloud IAM Service IDs and API Keys](
https://www.ibm.com/blogs/bluemix/2017/10/introducing-ibm-cloud-iam-service-ids-api-keys/)


## IBM Cloud の IAMとは

IBM Cloud Identity and Access Management (IAM) の略であり、大手クラウドベンダーと良く似たコンセプトで提供されています。

* [AWS Identity and Access Management (IAM)](https://aws.amazon.com/jp/iam/)
* [GCP Cloud Identity and Access Management](https://cloud.google.com/iam/docs/overview?hl=ja)
* [Azure Active Directory](https://azure.microsoft.com/en-us/services/active-directory/)


IAM は、IBM Cloud アカウントの管理下に、ユーザーとグループを作成して管理し、アクセス権を用いて、リソースへのアクセス許可、アクセスのレベルが設定できます。また、サービスID を利用した同様のアクセス管理もできます。

* IBM Cloud アカウントは、IBMクラウドの管理ユーザーで、契約書により、または、クレジットカードを登録して開設した時に作成される管理者ユーザーです。オペレーティングシステムのスーパーユーザーに相当する全てのアクセス権を持つユーザーです。

* リソースは、仮想サーバー、データベースなど、ユーザー用にインスタンス化されたサービスを表しています。また、カタログから作成ボタンをクリックしてインスタンス化する権限も含みます。

* アクセスレベルの設定とは、リソースの情報について、表示のみ、設定変更可能、新規作成、または、参照権限すら無しを設定するものです。

* サービスIDは、特定のユーザーに紐づくものではなく、前述のリソースに対応してアクセス権を管理します。ユーザーのアクセス権限は、組織の移動や退職などによって影響を受けますが、サービスIDは、影響を受けることがありません。この事から、アプリケーションのコードからリソースをアクセスする際に適しています。

#### 参考資料
[IBM Cloud Identity and Access Management](https://cloud.ibm.com/docs/iam?topic=iam-iamoverview#iamoverview)




## ユーザーの登録と管理

最初のユーザー登録は、アカウント管理者ユーザーが実施します。ユーザーとして登録する時のIDは、メールアドレスが利用されます。IBM IDとして登録されていないユーザーのメールアドレスも登録することができます。

* 既にIBMidを持つユーザーの場合は、ログイン後にユーザーを選択できるようになります。
* 新規のユーザーは、確認のメールが送信され、その指示に従いパスワード等を自主登録します。


ユーザーのアクセス権は、管理者ユーザーが実施します。そして、アクセス権の付与の方法は、以下の単位で実施することができます。

* アクセス・グループ
ユーザーをアクセス・グループに登録することで、グループが持つアクセス権を一括で付与されます。

* アクセス・ポリシー
ユーザー個別に、アクセス権を付与できます。　リソース・グループ と サービスに対してアクセス権の指定ができます。リソースグループは、事前に設定されている必要があります。初期状態では全てのリソースは、defaultに入っています。そして、サービスは、カタログから選択できるサービスと同じです。

* クラシック・インフラストラクチャー
旧SoftLayerのIaaSリソース（仮想サーバー、ベアメタル、VLAN、ストレージ）などのアクセス権を、当該ユーザーに対して設定できる。

* Cloud Foundry アクセス権
これは初期のBluemixの組織とユーザーを対応づけて、アクセス権を設定するもので、やはり、ユーザー個別に設定できる。

#### 参考資料
[ユーザーの招待](https://cloud.ibm.com/docs/iam?topic=iam-iamuserinv#iamuserinv)


## アクセス・グループ

これは前述のユーザーを、ここで作ったグループに登録することで、グループのアクセス権をユーザーに付与するものです。

以下３つのビルトインのアクセスグループが用意されています。これらはクラシック・インフラストラクチャーからの移行のために提供されるものです。

* Retrieve users　　ユーザーのリスト管理
* View account summary  アカウントのサマリーを表示
* View cases　　旧チケット（現在のServiceNowのCase)を参照

グループを作成して、ユーザーのアクセス権限管理を省力化できます。たとえば、IaaSの管理者グループにより、ベアメタルや仮想サーバーの管理ユーザーのアクセス権を管理、また、Kubernetes管理者グループを設定して、IKSクラスタと必要とするDBaaSを扱うグループを設定、DevOpsのグループを設定など、または、本番と開発のグループでも良いと思います。

アクセスグループには以下を含めることができます。

* ユーザー　　　ユーザーの名前を設定できる
* サービスID　　既に作成済のサービスIDを設定できる
* アクセス・ポリシー　　ユーザーの処で記述したのと同じ内容
* 動的ルール   SSOのプロバイダーと連携して認証とアクセス・グループの管理を実施


#### 参考資料
[アクセス・グループのセットアップ](https://cloud.ibm.com/docs/iam?topic=iam-groups#groups)


## サービスID

アプリケーションのコードから、クラウドのサービスにアクセスするために必要な認証情報として、APIキーという文字列を埋め込みます。そのAPIキーは、サービスIDの管理下に置かれ、アクセス・グループやアクセス・ポリシーによって、対象とするリソースやアクセスレベルを設定できます。

サービスIDは、サービスのインスタンス作成時に自動生成するか、または、ここで作成したサービスIDを選択します。


* アクセス・グループ　グループにサービスIDを含めることができる
* アクセス・ポリシー　対象とするリソースと権限を指定
* APIキー　　　　　　 アプリケーションからコールする時のキー（長い文字列）


#### 参考資料
[サービス ID の作成と処理](https://cloud.ibm.com/docs/iam?topic=iam-serviceids#serviceids)
[API キーについて](https://cloud.ibm.com/docs/iam?topic=iam-manapikey#manapikey)



## 許可と設定

許可は、サービスのインスタンスから、他のサービスをアクセスする許可を指定します。
設定は、ユーザーのログインで、多要素認証の利用、ユーザーリストの可視性の設定ができます。


マニュアルは読みたくないが、IAMついて、もう少し詳しい事知りたいかたは、「[IBM Cloud 新しい認証認可の仕組み(IBM Cloud IAM)の概要](https://qiita.com/masaffff/items/231a39d4bda7eac0ee80)」を参照ください。


#### 参考資料
[サービス間のアクセスの認可](https://cloud.ibm.com/docs/iam?topic=iam-serviceauth&locale=ja#-)
[アカウントのユーザーに MFA が必要](https://cloud.ibm.com/docs/iam?topic=iam-enablemfa&locale=ja#disablemfa)