Openstack mitaka のセキュリティ 講師：面 和毅 (サイオステクノロジー) アジェンダ： - Mitakaでの変更点 - 各コンポーネント - まとめ

1. © 2016 SIOS Technology, Inc. All rights Reserved.
OpenStack Mitakaのセキュリティ
1

2. © 2016 SIOS Technology, Inc. All rights Reserved.
Agenda
1. Mitakaでの変更点
2. 各コンポーネント
3. まとめ

3. © 2016 SIOS Technology, Inc. All rights Reserved.
自己紹介
3
 Linux/OSS歴18年
 OSSのセキュリティにフォーカス
 アクセス制御(SELinux, LIDS)
 AntiVirus
 SIEM
 SIer, ベンダ, 顧客（管理者）の立場を経験

4. © 2016 SIOS Technology, Inc. All rights Reserved.
1. Mitakaでの変更点
4

5. © 2016 SIOS Technology, Inc. All rights Reserved.
1. Mitakaでの変更点
5
 Mitakaで使い勝手と運用が改善された
 じゃあ、Liberty -> Mitakaでセキュリティはどう変わったか
 主なコンポーネントごとに変更点を見てみる
 Keystone, Neutron, Nova, Horizon, Cinder

6. © 2016 SIOS Technology, Inc. All rights Reserved.
2. 各コンポーネントでの変更点
6

7. © 2016 SIOS Technology, Inc. All rights Reserved.
2. 1 Keystone
7

8. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
8
Release Notesから
 [blueprint domain-specific-roles] Roles can now be optionally defined as domain specific. Domain specific roles are not referenced in policy files, rather they can be used to allow a
domain to build their own private inference rules with implied roles. A domain specific role can be assigned to a domain or project within its domain, and any subset of global roles it implies
will appear in a token scoped to the respective domain or project. The domain specific role itself, however, will not appear in the token.
 [blueprint bootstrap] keystone-manage now supports the bootstrap command on the CLI so that a keystone install can be initialized without the need of the admin_token filter in the
paste-ini.
 [blueprint domain-config-default] The Identity API now supports retrieving the default values for the configuration options that can be overriden via the domain specific configuration
API.
 [blueprint url-safe-naming] The names of projects and domains can optionally be ensured to be url safe, to support the future ability to specify projects using hierarchical naming.
 [bug 1490804] Audit IDs are included in the token revocation list.
 [bug 1519210] A user may now opt-out of notifications by specifying a list of event types using the notification_opt_out option in keystone.conf. These events are never sent to a
messaging service.
 [bug 1542417] Added support for a user_description_attribute mapping to the LDAP driver configuration.
 [bug 1526462] Support for posixGroups with OpenDirectory and UNIX when using the LDAP identity driver.
 [bug 1489061] Caching has been added to catalog retrieval on a per user ID and project ID basis. This affects both the v2 and v3 APIs. As a result this should provide a performance
benefit to fernet-based deployments.
 Keystone supports $(project_id)s in the catalog. It works the same as $(tenant_id)s. Use of $(tenant_id)s is deprecated and catalog endpoints should be updated to use $(project_id)s.
 [bug 1525317] Enable filtering of identity providers based on id, and enabled attributes.
 [bug 1555830] Enable filtering of service providers based on id, and enabled attributes.
 [blueprint federation-group-ids-mapped-without-domain-reference] Enhanced the federation mapping engine to allow for group IDs to be referenced without a domain ID.
 [blueprint implied-roles] Keystone now supports creating implied roles. Role inference rules can now be added to indicate when the assignment of one role implies the assignment of
another. The rules are of the form prior_role implies implied_role. At token generation time, user/group assignments of roles that have implied roles will be expanded to also include such
roles in the token. The expansion of implied roles is controlled by the prohibited_implied_role option in the [assignment] section of keystone.conf.
 [bug 96869] A pair of configuration options have been added to the [resource] section to specify a special admin project: admin_project_domain_name and admin_project_name. If these
are defined, any scoped token issued for that project will have an additional identifier is_admin_project added to the token. This identifier can then be checked by the policy rules in the
policy files of the services when evaluating access control policy for an API. Keystone does not yet support the ability for a project acting as a domain to be the admin project. That will be
added once the rest of the code for projects acting as domains is merged.
 [bug 1515302] Two new configuration options have been added to the [ldap] section. user_enabled_emulation_use_group_config and project_enabled_emulation_use_group_config, which
allow deployers to choose if they want to override the default group LDAP schema option.
 [bug 1501698] Support parameter list_limit when LDAP is used as identity backend.
 [bug 1479569] Names have been added to list role assignments (GET /role_assignments?include_names=True), rather than returning just the internal IDs of the objects the names are
also returned.
 Domains are now represented as top level projects with the attribute is_domain set to true. Such projects will appear as parents for any previous top level projects. Projects acting as
domains can be created, read, updated, and deleted via either the project API or the domain API (V3 only).
 [bug 1500222] Added information such as: user ID, project ID, and domain ID to log entries. As a side effect of this change, both the user’s domain ID and project’s domain ID are now
included in the auth context.
 [bug 1473042] Keystone’s S3 compatibility support can now authenticate using AWS Signature Version 4.
 [blueprint totp-auth] Keystone now supports authenticating via Time-based One-time Password (TOTP). To enable this feature, add the totp auth plugin to the methods option in the
[auth] section of keystone.conf. More information about using TOTP can be found in keystone’s developer documentation.
 [blueprint x509-ssl-client-cert-authn] Keystone now supports tokenless client SSL x.509 certificate authentication and authorization.
多すぎるので新機能をざっと説明

9. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
9
1. 暗黙の(Implied) ロール
 ロールの継承に似ているが
 複数の親から権限を引き継げる
 設定が簡単
 同じことを継承でやろうとすると、親が複数持てないため、
手間がかかる

10. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
10
 Reader Role: ReadOnly
 Editor Role: Read Only + Edit
 Neutron_admin: Read+Edit+Neutron Admin
 Swift_admin: Read+Edit+Swift Admin
 Storage_admin: Read+Edit+Swift Admin+Cinder_admin
通常の継承だと：
親が複数の時が大変
- 左図だと、storage_adminは
どっちを継承する？
-> swift_adminから継承し、
cinder_admin分の権限を再付与？
- all_adminだと、もっと困る。
-> neutron‗adminから継承
+いっぱい権限を再付与？

11. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
11
 Reader Role: ReadOnly
 Editor Role: Read Only + Edit
 Neutron_admin: Read+Edit+Neutron Admin
 Swift_admin: Read+Edit+Swift Admin
 Storage_admin: Read+Edit+Swift Admin+Cinder_admin
Implied Ｒｏｌｅだと
継承する親のロールをいくつでも書ける
下記のようになる（簡単）

12. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
12
2. Domain-Specific-Roleのサポート
 1. Implied Roleのコンセプトの拡張。Implied Roleの時の[Prior-
Role]として、ドメイン固有のロールを定義できる。
 通常、ドメインの管理者は自前の規則でロールを作る
 そのため、「ドメイン固有のロール」を新たに付け加える
 このロールは完全にプライベートであり、ドメインnamespace内
のみに存在する。その他のドメインは、このロールによる影響は
受けない
 さらに、この「ドメイン固有のロール」はトークンの中に現れな
い。

13. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
13
3. Time-based One Time Passwordのサポート
 時間ベースのOTP（TOTP：Time-based One Time Password RFC 6238)
 http://docs.openstack.org/developer/keystone/auth-totp.html
 二要素認証の導入によるセキュリティの向上
 Keystoneでは、デフォルトでは有効になっていない。
 Keystone.confファイルの【auth】を修正する
[auth] methods = external,password,token,oauth1,totp
 使用するには、TOTP Credential作成とＴＯＴＰデバイス
(google authenticatior)が必要

14. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
14
 TOTPデバイス(Google Authenticatior)とKeystoneとの連携(ユーザごと
のTOTP Credential作成)

15. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
15
4. X.509 クライアント証明書のサポート
 Kerberos認証と同じように、X.509もサポートするようになった。
 X.509とは？
 公開鍵証明書の規格の１つ
 公開鍵の正当性を保証する第3者機関 ： 認証局 (Certificate Authority)
 認証局では利用者と公開鍵の対を認証局（の秘密鍵）によるデジタル署名
した「公開鍵証明書」を発行
 この公開鍵証明書の規格の一つに、X.509がある。
 S/MIMEやSSLなどの多くのセキュリティプロトコルが X.509 をベースに
しているためデファクトスタンダードとなっている。

16. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
16
5. プロジェクト名とドメインに対してURLSafeをサポート。
 URL に Base64 されたバイナリデータを埋め込みたいけど、
+,/,= といった文字が入るのがイヤだな、という場合に使う
6. IdP(認証プロバイダ)からのGroupIDをドメイン参照無しに許可
 現在、フェデレーションのためIdPからKeystoneにグループ名のリストを提供できる。
 しかし、それぞれのGroupにドメインがマップされていなくてはならない。IdPでGroupID
への参照があった場合には、ドメイン参照無しにGroupのマップを直接Keystoneが行
えるようになった。

17. © 2016 SIOS Technology, Inc. All rights Reserved.
2-1. KeystoneのMitakaでの変更点
17
7. ユーザによるイベントのオプトアウト設定
 Keystoneは現在、様々なイベント通知をサポート
http://docs.openstack.org/developer/keystone/event_notifications.html
ユーザによるオプトアウト設定をサポート
-> 不要な情報を提供しない
-> セキュリティの向上

18. © 2016 SIOS Technology, Inc. All rights Reserved.
2. 2 Neutron
18

19. © 2016 SIOS Technology, Inc. All rights Reserved.
2-2. NeutronのMitakaでの変更点
19
1. External networksがRBACフレームワークを用いて制御
 Libertyで追加。
 https://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html
 http://docs.openstack.org/ja/networking-guide/adv_config_network_rbac.html
 テナント間のNeutronネットワークの共有を制御

20. © 2016 SIOS Technology, Inc. All rights Reserved.
2-2. NeutronのMitakaでの変更点
20
 External networksがRBACフレームワークを用いて制御
 この時点で、プロジェクト e28769db97d9449da658bc6931fcb683 が net-
list や net-show を実行すると、このネットワークが見える。
 他のユーザーにはこのネットワークは見えない。

21. © 2016 SIOS Technology, Inc. All rights Reserved.
2-2. NeutronのMitakaでの変更点
21
2. セキュリティグループに、OpenFlowを使ったファイアウォールが導入
 ovs-firewall-driver
 https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver
 OVS2.5/kernel 4.3以降が必要
 https://github.com/openvswitch/ovs/blob/master/FAQ.md

22. © 2016 SIOS Technology, Inc. All rights Reserved.
2-2. NeutronのMitakaでの変更点
22
 セキュリティグループに、OpenFlowを使ったファイアウォールが導入
 今まではiptablesベースのファイアウォールだけだった
 agent/linux/iptables_firewall.py
 今後はopenvswitchベースのファイアウォールも使用可能
 agent/linux/openvswitch_firewall以下

23. © 2016 SIOS Technology, Inc. All rights Reserved.
2. 3 Nova
23

24. © 2016 SIOS Technology, Inc. All rights Reserved.
2-3. NovaのMitakaでの変更点
24
1. LibvirtでUEFIブート対応
 UEFIセキュアブートでのインストールが可能?
-> 要調査(m(__)m)

25. © 2016 SIOS Technology, Inc. All rights Reserved.
2. 4 Horizon
25

26. © 2016 SIOS Technology, Inc. All rights Reserved.
2-4. HorizonのMitakaでの変更点
26
1. Keystone v3.を使用している際のドメインとプロジェクトの管理機能が追加
 Horizonを用いてドメインロールに所属しているユーザのドメインを管理したり、
プロジェクトロールに所属しているユーザのプロジェクトを管理することが可能
になった。
2. Keystone ID Providerの管理をサポート
3. Keystoneでのフェデレーションマッピングの基本的なサポートを追加
4. ドメイン管理で次のユースケースをサポート：
 Cloud Admin – ドメインにまたがるリソースのＩＤの表示と管理
 Domain Admin – ログインしているドメインのリソースIDの表示と管理
 User – ログインしているドメインのプロジェクトＩＤの表示

27. © 2016 SIOS Technology, Inc. All rights Reserved.
2. 5 Cinder
27

28. © 2016 SIOS Technology, Inc. All rights Reserved.
2-5. CinderのMitakaでの変更点
28
 NetAppドライバでのiSCSI CHAP 単方向 認証の追加
ターゲットは、接続要求が本当に指定されたホストからのものなのかを判断できない。
チャレンジハンドシェーク認証プロトコル (CHAP) を使ってイニシエータを認証
「チャレンジ」と「応答」により、ターゲットがイニシエータに対して身元の証明を要求
する。
iSCSI は、単方向および双方向の認証をサポート。
「単方向認証」: ターゲットがイニシエータの身元を認証。
「双方向認証」: イニシエータがターゲットの身元を認証 -> イニシエータ主導

29. © 2016 SIOS Technology, Inc. All rights Reserved.
5. まとめ
29

30. © 2016 SIOS Technology, Inc. All rights Reserved.
Mitakaでの主なセキュリティ変更点
30
 Keystone、Neutronにはいくつかの追加点がある
 Keystone: Implied/Domain-Specific Role、OTOP
 Neutron: OVSを用いたFirewall、RBACでのネットワーク制御
 その他のコンポーネントでは、あまりセキュリティ上の追加は見
られない
 ほぼ機能は固まってきているからか？
 フェデレーション、OTOPに関しては検証が必要
 検証結果はなんとか共有したい。

31. © 2016 SIOS Technology, Inc. All rights Reserved.