Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月
-
Upload
virtualtech-japan-inc -
Category
Technology
-
view
890 -
download
2
Transcript of Openstack mitaka のセキュリティ - OpenStack最新情報セミナー 2016年5月
© 2016 SIOS Technology, Inc. All rights Reserved.
OpenStack Mitaka のセキュリティ
1
© 2016 SIOS Technology, Inc. All rights Reserved.
Agenda
1. Mitaka での変更点
2. 各コンポーネント
3. まとめ
© 2016 SIOS Technology, Inc. All rights Reserved.
自己紹介
3
Linux/OSS 歴 18 年 OSS のセキュリティにフォーカス
アクセス制御 (SELinux, LIDS) AntiVirus SIEM
SIer, ベンダ , 顧客(管理者)の立場を経験
© 2016 SIOS Technology, Inc. All rights Reserved.
1. Mitaka での変更点
4
© 2016 SIOS Technology, Inc. All rights Reserved.
1. Mitaka での変更点
5
Mitaka で使い勝手と運用が改善された じゃあ、 Liberty -> Mitaka でセキュリティはどう変
わったか
主なコンポーネントごとに変更点を見てみる Keystone, Neutron, Nova, Horizon, Cinder
© 2016 SIOS Technology, Inc. All rights Reserved.
2. 各コンポーネントでの変更点
6
© 2016 SIOS Technology, Inc. All rights Reserved.
2. 1 Keystone
7
© 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.
多すぎるので新機能をざっと説明
© 2016 SIOS Technology, Inc. All rights Reserved.
2-1. Keystone の Mitaka での変更点
9
1. 暗黙の (Implied) ロール ロールの継承に似ているが
複数の親から権限を引き継げる 設定が簡単 同じことを継承でやろうとすると、親が複数持てな
いため、手間がかかる
© 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 から継承 + いっぱい権限を再付与?
© 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 Roleだと継承する親のロールをいくつでも書ける下記のようになる(簡単)
© 2016 SIOS Technology, Inc. All rights Reserved.
2-1. Keystone の Mitaka での変更点
12
2. Domain-Specific-Role のサポート
1. Implied Role のコンセプトの拡張。 Implied Role の時の [Prior-Role] として、ドメイン固有のロールを定義できる。
通常、ドメインの管理者は自前の規則でロールを作る そのため、「ドメイン固有のロール」を新たに付け加える このロールは完全にプライベートであり、ドメイン namespace
内のみに存在する。その他のドメインは、このロールによる影響は受けない
さらに、この「ドメイン固有のロール」はトークンの中に現れない。
© 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 作成とTOTPデバイス (google authenticatior) が必要
© 2016 SIOS Technology, Inc. All rights Reserved.
2-1. Keystone の Mitaka での変更点
14
TOTP デバイス (Google Authenticatior) と Keystone との連携( ユーザごとの TOTP Credential 作成 )
© 2016 SIOS Technology, Inc. All rights Reserved.
2-1. Keystone の Mitaka での変更点
15
4. X.509 クライアント証明書のサポート Kerberos 認証と同じように、 X.509 もサポートするようになった。
X.509 とは? 公開鍵証明書の規格の1つ 公開鍵の正当性を保証する第 3 者機関 : 認証局 (Certificate Authority)
認証局では利用者と公開鍵の対を認証局(の秘密鍵)によるデジタル署名した「公開鍵証明書」を発行
この公開鍵証明書の規格の一つに、 X.509 がある。
S/MIME や SSL などの多くのセキュリティプロトコルが X.509 をベースにしているためデファクトスタンダードとなっている。
© 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 が行えるようになった。
© 2016 SIOS Technology, Inc. All rights Reserved.
2-1. Keystone の Mitaka での変更点
17
7. ユーザによるイベントのオプトアウト設定 Keystone は現在、様々なイベント通知をサ
ポートhttp://
docs.openstack.org/developer/keystone/event_notifications.htmlユーザによるオプトアウト設定をサポート
-> 不要な情報を提供しない
-> セキュリティの向上
© 2016 SIOS Technology, Inc. All rights Reserved.
2. 2 Neutron
18
© 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 ネットワークの共有を制御
© 2016 SIOS Technology, Inc. All rights Reserved.
2-2. Neutron の Mitaka での変更点
20
External networks が RBAC フレームワークを用いて制御
この時点で、プロジェクト e28769db97d9449da658bc6931fcb683 がnet-list や net-show を実行すると、このネットワークが見える。
他のユーザーにはこのネットワークは見えない。
© 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
© 2016 SIOS Technology, Inc. All rights Reserved.
2-2. Neutron の Mitaka での変更点
22
セキュリティグループに、 OpenFlow を使ったファイアウォールが導入 今までは iptables ベースのファイアウォールだけだった agent/linux/iptables_firewall.py 今後は openvswitch ベースのファイアウォールも使用可能 agent/linux/openvswitch_firewall以下
© 2016 SIOS Technology, Inc. All rights Reserved.
2. 3 Nova
23
© 2016 SIOS Technology, Inc. All rights Reserved.
2-3. Nova の Mitaka での変更点
24
1. Libvirt で UEFIブート対応
UEFI セキュアブートでのインストールが可能 ? -> 要調査 (m(__)m)
© 2016 SIOS Technology, Inc. All rights Reserved.
2. 4 Horizon
25
© 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 – ドメインにまたがるリソースのIDの表示と管理 Domain Admin – ログインしているドメインのリソース ID の表示と管理 User – ログインしているドメインのプロジェクトIDの表示
© 2016 SIOS Technology, Inc. All rights Reserved.
2. 5 Cinder
27
© 2016 SIOS Technology, Inc. All rights Reserved.
2-5. Cinder の Mitaka での変更点
28
NetApp ドライバでの iSCSI CHAP 単方向 認証の追加
ターゲットは、接続要求が本当に指定されたホストからのものなのかを判断できない。
チャレンジハンドシェーク認証プロトコル (CHAP) を使ってイニシエータを認証「チャレンジ」と「応答」により、ターゲットがイニシエータに対して身元の証明を要求する。
iSCSI は、単方向および双方向の認証をサポート。
「単方向認証」 : ターゲットがイニシエータの身元を認証。
「双方向認証」 : イニシエータがターゲットの身元を認証 -> イニシエータ主導
© 2016 SIOS Technology, Inc. All rights Reserved.
5. まとめ
29
© 2016 SIOS Technology, Inc. All rights Reserved.
Mitaka での主なセキュリティ変更点
30
Keystone 、 Neutron にはいくつかの追加点がある Keystone: Implied/Domain-Specific Role 、 OTOP Neutron: OVS を用いた Firewall 、 RBAC でのネット
ワーク制御
その他のコンポーネントでは、あまりセキュリティ上の追加は見られない
ほぼ機能は固まってきているからか?
フェデレーション、 OTOP に関しては検証が必要検証結果はなんとか共有したい。
© 2016 SIOS Technology, Inc. All rights Reserved.