第32章 ストラテジーによるビルドのセキュリティー保護
32.1. 概要
OpenShift Container Platform のビルドは、Docker デーモンソケットにアクセスできる特権付きコンテナーで実行されます。セキュリティー対策として、ビルドおよびそれらのビルドに使用されるストラテジーを実行するユーザーを制限することを推奨します。カスタムビルドは、ソースビルドよりも安全性が低いと言えます。それらはノードの Docker ソケットへの完全なアクセスを持つ可能性があり、それらのアクセスでビルド内で任意のコードを実行する可能性があるためです。そのため、これはデフォルトで無効にされます。Docker ビルドのパーミッションを付与する場合についても、Docker ビルドロジックの脆弱性により権限がホストノードで付与される可能性があるために注意が必要です。
デフォルトで、ビルドを作成できるすべてのユーザーには Docker および Source-to-Image (S2I) ビルドストラテジーを使用するためのパーミッションが付与されます。cluster-admin 権限を持つユーザーは、このページの「ユーザーへのビルドストラテジーのグルーバルな制限」セクションで言及されているようにカスタムビルドストラテジーを有効にすることができます。
許可ポリシーを使用して、どのユーザーがどのビルドストラテジーを使用してビルドできるかについて制限することができます。各ビルドには、対応するビルドサブリソースがあります。ストラテジーを使用してビルド作成するには、ユーザーにビルドを作成するパーミッション および ビルドストラテジーのサブリソースで作成するパーミッションがなければなりません。ビルドストラテジーのサブリソースでの create パーミッションを付与するデフォルトロールが提供されます。
| ストラテジー | サブリソース | ロール |
|---|---|---|
|
Docker |
ビルド/docker |
system:build-strategy-docker |
|
Source-to-Image (S2I) |
ビルド/ソース |
system:build-strategy-source |
|
カスタム |
ビルド/カスタム |
system:build-strategy-custom |
|
JenkinsPipeline |
ビルド/jenkinspipeline |
system:build-strategy-jenkinspipeline |
32.2. ビルドストラテジーのグローバルな無効化
特定のビルドストラテジーへのアクセスをグローバルに禁止するには、cluster-admin 権限を持つユーザーとしてログインし、system:authenticated グループから対応するロールを削除し、アノテーション openshift.io/reconcile-protect: "true" を適用してそれらを API の再起動間での変更から保護します。以下の例では、Docker ビルドストラテジーを無効にする方法を示します。
openshift.io/reconcile-protectアノテーションの適用$ oc edit clusterrolebinding system:build-strategy-docker-binding apiVersion: v1 groupNames: - system:authenticated kind: ClusterRoleBinding metadata: annotations: openshift.io/reconcile-protect: "true" 1 creationTimestamp: 2018-08-10T01:24:14Z name: system:build-strategy-docker-binding resourceVersion: "225" selfLink: /oapi/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bf roleRef: name: system:build-strategy-docker subjects: - kind: SystemGroup name: system:authenticated userNames: - system:serviceaccount:management-infra:management-admin- 1
openshift.io/reconcile-protectアノテーションの値を"true"に適用します。デフォルトで、これは"false"に設定されます。
ロールを削除します。
$ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated
3.2 よりも前のバージョンでは、ビルドストラテジーのサブリソースは admin および edit ロールに組み込まれていました。
ビルドストラテジーのサブリソースもこれらのロールから削除されることを確認します。
$ oc edit clusterrole admin $ oc edit clusterrole edit
それぞれのロールについて、無効にするストラテジーのリソースに対応する行を削除します。
admin の Docker ビルドストラテジーの無効化
kind: ClusterRole
metadata:
name: admin
...
rules:
- resources:
- builds/custom
- builds/docker 1
- builds/source
...
...
- 1
- admin ロールを持つユーザーに対して Docker ビルドをグローバルに無効にするためにこの行を削除します。
32.3. ユーザーへのビルドストラテジーのグルーバルな制限
一連の特定ユーザーのみが特定のストラテジーでビルドを作成できるようにするには、以下を実行します。
- ビルドストラテジーへのグローバルアクセスを無効にします。
ビルドストラテジーに対応するロールを特定ユーザーに割り当てます。たとえば、system:build-strategy-docker クラスターロールをユーザー devuser に追加するには、以下を実行します。
$ oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser
ユーザーに対して builds/docker サブリソースへのクラスターレベルでのアクセスを付与することは、そのユーザーがビルドを作成できるすべてのプロジェクトにおいて、Docker ストラテジーを使ってビルドを作成できることを意味します。
32.4. プロジェクト内でのユーザーへのビルドストラテジーの制限
ユーザーにビルドストラテジーをグローバルに付与するのと同様に、プロジェクト内の特定ユーザーのセットのみが特定ストラテジーでビルドを作成できるようにするには、以下を実行します。
- ビルドストラテジーへのグローバルアクセスを無効にします。
ビルドストラテジーに対応するロールをプロジェクト内の特定ユーザーに付与します。たとえば、プロジェクト devproject 内の system:build-strategy-docker ロールをユーザー devuser に追加するには、以下を実行します。
$ oc adm policy add-role-to-user system:build-strategy-docker devuser -n devproject
