本資料は、OpenStack Summit Austinのセッション “Get Ready for Fernet Tokens(https://www.youtube.com/watch?v=702SRZHdNW8&feature=share)” を下記の点を中心に自分なりに噛み砕き、まとめた資料である。 ・「なぜ必要か」 ・「Fernet Tokenはどんなものか」 ・「実際にどのように使われているか(ユーザ事例)」 セッションで言及されてないことも、後で調べて追加していたりします。

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

2. 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-learned
IBM 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

3. はじめに
我々は、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

4. なぜ、Fernet Tokenが必要なのか
UUID: 永続的にtokenを保持する必要がある
=> Token Tableが大きくなるとパフォーマンスに影響がでる。
PKI:１つのTokenのサイズが大きすぎる
PKIZ: PKI Tokenをzlib libraryを使って圧縮したものだが、まだサイズが大きい
Fernet: サイズが小さい/永続的にtokenを保持しない
● data replicationのコストが低い
● replication lag が発生しない
● database cleanup をしなくていい
● token validation が難しい
● token revocation が難しい

5. 設定方法
[token]
provider = fernet
expiration = 864000
[fernet_tokens]
key_repository = /etc/keystone/fernet-keys/
max_active_keys = 3
keystone.conf

6. Token generation
payload = msgpack(user_id + project_id + expiration)
#=> keystone token providerで実施
#=> MessagePack(バイナリベースのシリアライズ形式)
decoded = version + timestamp + AES(payload) + HMAC
token = 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
で作られる。

7. Fernet Token Validation
fernet key
repository
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

8. Life of encryption key
● ユーザ情報などをTokenに埋め込むが、「暗号化」しているのでTokenが漏れても
ユーザ情報がもれないようにしている
○ Fernet Keyは256bit ( encryption部128bit / sign部128bit)
○ 鍵は定期的に変更した方が、安全性を高められる
● 鍵をRotationさせて、定期的に変更させる仕組みがある。

9. 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-manage
fernet_setup
鍵のコピー
(rsync/orchestration tool)
1
2

10. 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-manage
fernet_rotate
3
Primary
Staged
Previous

11. 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により消失すること

12. Time warner cableの導入事例のFeedback(2/2)
● ２つのRegionで同時に、Rotationしない。
○ ２日程度遅らせて、１つの Regionで問題がないことを確認してから入れる
● ３、４週間に１回鍵を Rotationする
● Cacheは、絶対設定した方がいい => memcache
● Fernet Tokenにしてから
○ keystoneのdb tableがかなり小さくなった
○ 使えなくなったtokenを定期的に削除する cronjobが必要なくなった
○ Multi Regionでtoken dataをreplicationしなくてよくなった
■ ３、４週間に１度鍵を同期させるだけ

13. 所感
● NewtonでDefault Driverが変更されるので、内部動作の概要を知ることは大事で
あり、そのきっかけとなる良いセッションだった。
○ しかし、セッション中に紹介されている Token Formatは、間違っていたように見えたのでソースコー
ドを読むハメに。。。
■ payloadのhash値がtokenであるという説明に見えた (hash値じゃ複合できなくないか。。。 )
● Fernet Tokenの運用の話(Time waner Cableの事例)は、非常に貴重だった。こう
いう情報は、なかなか世に出回らないのでこれでも聞く価値があった
○ でも、まさか鍵のローテーションに Gerritを挟んでるとは思わなかった。
● 発表の構成が綺麗で、「新機能の内部動作説明」+「実際に使われている事例の紹
介」の組み合わせは、かなり魅力的だと思った。今後発表する際の参考にしたい。