Keystoneの動作と仕組み～エンドポイントと認証認可

マイクロサービスアーキテクチャが支えるOpenStackの動作と仕組み 第1回

認証

Keystoneによる認証の手順

Keystoneによる認証は、次の3者のやり取りによって行われます。

• クライアント
• Keystone
• データベース

Keystoneの認証はクライアントを起点とします。クライアントがユーザーIDとパスワードをKeystoneに送信します。

Keystoneはクライアントから受け取ったIDとパスワードを、検証のためにデータベースに送信します。IDとパスワードの対が見つかれば、クライアントから受け取ったIDの対は正しく、対が見つからなければ、間違ったIDないしはパスワードをクライアントは送信した、ということになります。

IDとパスワードの対が正しければ、KeystoneはTokenを作成します。作成したTokenはデータベースに記録された後に、クライアントに送信されます。このようにしてTokenがクライアントに共有されれば一連の手順は終了です。

次の通信から、クライアントはこのTokenを用いて通信を行います。

Keystoneの認証手順

権限をテナントごとに割り振ることで柔軟な権限管理を可能に

MSAは比較的大規模なサービスの構築で採用されます。OpenStackもその一例です。そのような大規模なサービスで頻出する問題の1つに、「権限の細かい制御」があります。Keystoneはこの課題にテナントとロールという2つの概念で対応しています。

テナントは概念的な区切りをOpenStackに与える機能です。OpenStackを利用するユーザーは1つ以上のテナントに登録されます。各ユーザーは原則として自分の所属しているテナントに対してのみ操作が可能です。

テナントの使い方として、会社であれば「部門ごとにテナントを割り振る」といったやり方があります。人事部、会計製品開発部、人事製品開発部、営業部、財務部という5つの部がある会社でOpenStackを使うとしましょう。その場合、管理者は部門ごとのテナントを作成します。この場合は5つのテナントを作成します。その上で、管理者は全ての社員のアカウントを作成し、全ての社員をいずれかのテナントに所属させます。また、複数部門に兼務する社員については2つ以上のテナントに同時に所属させます。

一方、ロールはテナントに属したユーザーに与えられる権限の種類です。例えば、会社であればマネジメントをしていない人には一般ユーザー権限を、マネジメントをしている人には一般ユーザー権限とマネージャ権限の双方を与える、といったことが考えられます。また、マネジメントしかせず、一般ユーザーとしては一切活動しない人がいるしたら、その人には一般ユーザー権限は与えず、マネージャ権限のみを与える、といったやり方も考えられます。

また、1人のユーザーに、テナントごとに異なるロールを与えることもできます。例えば、会計製品開発部でマネージャをやっている人がいるとしましょう。この人は、会計製品開発部用のテナントに、一般ユーザー権限とマネージャ権限を持つユーザーとして登録されます。しかし、人事製品開発部から要請があり、急遽人事製品の開発を手伝うことになりました。人事製品開発部においてこの人はマネージャではありませんから、一般ユーザー権限が割り振られます。

複雑な権限管理をシンプルに

このようにKeystoneは、複数のテナントに異なる権限でユーザーを登録できるようになっています。また、この実装方法は、複雑な権限制御をシンプルにしてくれています。

Keystoneが認証について扱う情報

Keystoneで認証を行う場合、クライアントは以下の情報を送信します。

クライアントがKeystoneに送信する情報

項目	説明
ユーザーID	ユーザーを一意に識別するための名前
パスワード	ユーザーIDに対応するパスワード
テナント名	どのテナントに関するエンドポイントおよびロールの情報を受け取るのかを指定

認証が成功した場合、Keystoneは次のような返り値をクライアントに送ります。

認証が成功した場合にKeystoneがクライアントに送る返り値

{
    "access": {
        "metadata":
            "is_admin": 0,
            "roles": [
                "0c4a76b94ed74057ae986a956b90b90c"
            ]
        },
        "serviceCatalog": [
            {
                "endpoints": [
                    {
                        "adminURL": "http://nova.privatenetwork.exampla.com:8774/v2/c7e5e14e38e9438da15ea276c1a04798",
                        "id": "411289be7d7e44e3aaec71666cadea0e",
                        "internalURL": "http://nova.servicenetwork.exampla.com:8774/v2/c7e5e14e38e9438da15ea276c1a04798",
                        "publicURL": "http://nova.publicnetwork.exampla.com:8774/v2/c7e5e14e38e9438da15ea276c1a04798",
                        "region": "SampleRegion"
                    }
                ],
                "endpoints_links": [],
                "name": "nova",
                "type": "compute"
            },
            {
                "endpoints": [
                    {
                        "adminURL": "http://neutron.privatenetwork.exampla.com:9696",
                        "id": "0325a57169214b0ba1c21fdd0cfc04a4",
                        "internalURL": "http://neutron.servicenetwork.exampla.com:9696",
                        "publicURL": "http://neutron.publicnetwork.exampla.com:9696",
                        "region": "SampleRegion"
                    }
                ],
                "endpoints_links": [],
                "name": "neutron",
                "type": "network"
            },
            {
                "endpoints": [
                    {
                        "adminURL": "http://keystone.privatenetwork.exampla.com:35357/v2.0",
                        "id": "18c95b3f24a04b1ab1efbeeedc4a40b6",
                        "internalURL": "http://keystone.servicenetwork.exampla.com:5000/v2.0",
                        "publicURL": "http://keystone.publicnetwork.exampla.com:5000/v2.0",
                        "region": "SampleRegion"
                    }
                ],
                "endpoints_links": [],
                "name": "keystone",
                "type": "identity"
            }
        ],
        "token": {
            "audit_ids": [
                "vG3FV2TsQMiXGwK32bNxQg"
            ],
            "expires": "2016-08-24T02:43:58Z",
            "id": "0d7c62e9c746418c879779e18c351588",
            "issued_at": "2016-08-24T01:43:58.335954",
            "tenant": {
                "description": "Demonstration Tenant",
                "enabled": true,
                "id": "c7e5e14e38e9438da15ea276c1a04798",
                "name": "demo"
            }
        },
        "user": {
            "id": "4f525d938c244788b6bb44f5ee3b5f8c",
            "name": "user",
            "roles": [
                {
                    "name": "user"
                }
            ],
            "roles_links": [],
            "username": "user"
        }
    }
}

Keystoneからクライアントへ送られる返り値

項目	説明
metadata	認証したユーザーの権限に関するサマリー。管理者権限を持っているか否かの情報と、テナント上でユーザーに割り当てられているロールが記述される
serviceCatalog	指定したテナントに関する、エンドポイントの一覧が記述される。詳細は先述のKeystoneがエンドポイントについて扱う情報を確認のこと
token	ユーザーが何らかの操作を行う際に、本人確認のために使うTokenに関する情報が記述される。使うべきTokenや利用期限、そのTokenでアクセスできるテナント情報など
user	ユーザーの詳細な情報が記述される。ロールやユーザーIDなどが含まれる

認証の結果として得られるTokenは、認可のために使う重要な情報となります。このTokenがなければ、OpenStackにおけるあらゆる操作が行えません（これ以上のことについては後述の認可の解説で説明します）。

TokenでアクセスできるテナントはTokenごとに異なります。そのため、別のテナントに関するエンドポイントおよびロールの情報が必要ならば、再度認証を行う必要があります。

また、Keystoneはユーザーの認証のために次の情報をデータベースに格納しています。

Keystoneがユーザー認証のためデータベースに格納している情報

項目	説明
id	ユーザーを一意に識別するID
name	ユーザーの名前。ユーザーは多くの場合こちらの値を用いてアクセスする
password	パスワードをハッシュ化したもの。実際の値ではない
enabled	ユーザーが有効か否か

ロールについては以下の情報のみを格納しています。

Keystoneがデータベースに格納しているロールの情報

項目	説明
ID	ロールを一意に識別するID
name	ロールに与えられた名前

どのユーザーにどのロールが割り当てられているかの情報は、Keystoneが保有しています。しかし、ロールそのものが持つ権限といった情報は、Keystoneは保有していません。ロールが持つ権限の情報は各サービスが保有します。

TokenについてKeystoneが保持する情報は次のとおりです。

TokenについてKeystoneが保持する情報

項目	説明
ID	Tokenを一意に識別するID
expires	Tokenの有効期限
valid	Tokenが有効か否か
trust_id	このTokenにはどのRoleが割り振られているのかを示す
user_id	どのユーザーのTokenであるかを示す