13
Keystone fernet token OpenStack Summit Austin報告 (2/2) Yuki Nishiwaki

Keystone fernet token

Embed Size (px)

Citation preview

Keystone fernet token

OpenStack Summit Austin報告 (2/2)

Yuki Nishiwaki

My material

本資料は、OpenStack Summit Austinのセッション

“Get Ready for Fernet Tokens(https://www.youtube.com/watch?v=702SRZHdNW8&feature=share)”

を下記の点を中心に自分なりに噛み砕き、まとめた資料である。

● 「なぜ必要か」

● 「Fernet Tokenはどんなものか」

● 「実際にどのように使われているか(ユーザ事例)」

[参考]上記セッション以外に、参考にしたfernet tokenに関する記事OpenStack Tokyo Summit http://www.slideshare.net/priti_desai/deep-dive-into-keystone-tokens-and-lessons-learnedIBM Open Tech blog https://developer.ibm.com/opentech/2015/11/11/deep-dive-keystone-fernet-tokens/OpenStack Wiki FAQ http://docs.openstack.org/admin-guide/keystone_fernet_token_faq.html

はじめに

我々は、Fernet Tokenへの切り替えを検討した方がいい: ● NewtonでKeystoneのdefault token driverが「UUID -> fernet」に変わる

● インストーラに関するプロジェクトでも、fernet tokenに切り替えようという意見が出

てる

○ Fuel: https://blueprints.launchpad.net/fuel/+spec/fernet-tokens-support○ Kolla: https://blueprints.launchpad.net/kolla/+spec/keystone-fernet-token

なぜ、Fernet Tokenが必要なのか

UUID: 永続的にtokenを保持する必要がある

=> Token Tableが大きくなるとパフォーマンスに影響がでる。

PKI:1つのTokenのサイズが大きすぎる

PKIZ: PKI Tokenをzlib libraryを使って圧縮したものだが、まだサイズが大きい

Fernet: サイズが小さい/永続的にtokenを保持しない

● data replicationのコストが低い

● replication lag が発生しない

● database cleanup をしなくていい

● token validation が難しい

● token revocation が難しい

設定方法

[token]provider = fernetexpiration = 864000

[fernet_tokens]key_repository = /etc/keystone/fernet-keys/max_active_keys = 3

keystone.conf

Token generation

payload = msgpack(user_id + project_id + expiration) #=> keystone token providerで実施

#=> MessagePack(バイナリベースのシリアライズ形式)

decoded = version + timestamp + AES(payload) + HMACtoken = base64(decoded) #=> 暗号化ライブラリ(https://github.com/pyca/cryptography)内で実施

#=> token providerは、payloadをcryptographyに渡すだけ

詳細はこちらを : https://github.com/openstack/keystone/tree/master/keystone/token/providers/fernet

この鍵がkeyston-manage fernet_setupで作られる。

Fernet Token Validation

fernet keyrepository

keystone-manage● fernet_setup● fernet_rotate

Get the key for encryption/sign(local)

decrypt token

determine the version from payload (what scope)

fernet token

Keystone

Disassemble payload(user id, project id….)

Expire ? or

Revoked ?

If error: Token is invalid

Token is valid

Token is invalid

Operator

User

Life of encryption key ● ユーザ情報などをTokenに埋め込むが、「暗号化」しているのでTokenが漏れても

ユーザ情報がもれないようにしている○ Fernet Keyは256bit ( encryption部128bit / sign部128bit)○ 鍵は定期的に変更した方が、安全性を高められる

● 鍵をRotationさせて、定期的に変更させる仕組みがある。

Life of encryption key on Cluster

node1 node2 node3

Staged Key: next primary key↓

Primary Key: encrypt and decrypt↓

Secondary Keys: decrypt only↓

Remain or Delete

max_active_keys = 3

Staged

Primary

鍵の生成keystone-managefernet_setup

鍵のコピー(rsync/orchestration tool)

1

2

Life of encryption key on Cluster

node1 node2 node3

Staged Key: next primary key↓

Primary Key: encrypt and decrypt↓

Secondary Keys: decrypt only↓

Remain or Delete

max_active_keys = 3

Staged

Secondary

鍵のコピー(rsync/orchestration tool)

4

Primary

鍵のローテーションkeystone-managefernet_rotate

3

Primary Staged

Previous

Time warner cableの導入事例のFeedback(1/2)● 環境

○ Mutli Region (Galera Cluster)○ dockerでデプロイしている (全部か一部かは、不明 )○ Liberty Keystone + mixed version other service○ Fernet tokenを2015年7月から利用

● KeystoneのUpgradeに使用したPlaybook○ https://github.com/matthewfischer/ansible/tree/master/keystone-upgrade

● Libertyでは、数秒の断タイムで切り替え可能

● Kilo → Libertyで、Fernet Tokenのフォーマットに変更があった

○ Kiloの人は、Libertyまで待った方がいい

● Key rotationにkeystone-manageは使っていない

○ EYAML (Yamlを暗号化したもの )にkeyを入れたPuppetで配布

○ Keyの変更は、Gerritでreviewしてる

■ Keyのformatチェックなどが、目的ではなく。 Over Rotationを避けることが目的

● Over Rotationとは、tokenのexpireより前に、tokenの復号鍵がRotationにより消失すること

Time warner cableの導入事例のFeedback(2/2)● 2つのRegionで同時に、Rotationしない。

○ 2日程度遅らせて、1つのRegionで問題がないことを確認してから入れる

● 3、4週間に1回鍵をRotationする

● Cacheは、絶対設定した方がいい => memcache● Fernet Tokenにしてから

○ keystoneのdb tableがかなり小さくなった

○ 使えなくなった tokenを定期的に削除する cronjobが必要なくなった

○ Multi Regionでtoken dataをreplicationしなくてよくなった

■ 3、4週間に1度鍵を同期させるだけ

所感

● NewtonでDefault Driverが変更されるので、内部動作の概要を知ることは大事で

あり、そのきっかけとなる良いセッションだった。

○ しかし、セッション中に紹介されている Token Formatは、間違っていたように見えたのでソースコー

ドを読むハメに。。。

■ payloadのhash値がtokenであるという説明に見えた (hash値じゃ複合できなくないか。。。 )

● Fernet Tokenの運用の話(Time waner Cableの事例)は、非常に貴重だった。こう

いう情報は、なかなか世に出回らないのでこれでも聞く価値があった○ でも、まさか鍵のローテーションに Gerritを挟んでるとは思わなかった。

● 発表の構成が綺麗で、「新機能の内部動作説明」+「実際に使われている事例の紹

介」の組み合わせは、かなり魅力的だと思った。今後発表する際の参考にしたい。