このドキュメントでは、GKE on Bare Metal クラスタのセキュリティを強化する方法について説明します。
SELinux を使用してコンテナを保護する
Red Hat Enterprise Linux（RHEL）と CentOS でサポートされている SELinux を有効にすることで、コンテナを保護できます。ホストマシンが RHEL または CentOS を実行している場合で、クラスタで SELinux を有効にするには、すべてのホストマシンで SELinux を有効にする必要があります。詳細については、SELinux を使用してコンテナを保護するをご覧ください。
seccomp を使用してコンテナを制限する
セキュア コンピューティング モード（seccomp）は、GKE on Bare Metal のバージョン 1.11 で利用できます。seccomp プロファイルを使用してコンテナを実行すると、コンテナがカーネルに対して実行できるシステム呼び出しが制限されるため、クラスタのセキュリティが向上します。これにより、カーネルの脆弱性が悪用される可能性が低くなります。
デフォルトの seccomp プロファイルには、コンテナが実行できるシステムコールのリストが含まれています。このリストにないシステムコールは許可されません。GKE on Bare Metal のバージョン 1.11 では、seccomp がデフォルトで有効になっています。これは、すべてのシステム コンテナとお客様のワークロードが、コンテナ ランタイムのデフォルトの seccomp プロファイルで実行されることを意味します。構成ファイルで seccomp プロファイルを指定していないコンテナとワークロードも、seccomp の制限が適用されます。
クラスタ全体または特定のワークロードで seccomp を無効にする方法
seccomp は、クラスタの作成時またはクラスタのアップグレード時にのみ無効にできます。bmctl update を使用してこの機能を無効にすることはできません。クラスタ内で seccomp を無効にする場合は、次の clusterSecurity セクションをクラスタの構成ファイルに追加します。
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: example
namespace: cluster-example
spec:
...
clusterSecurity:
enableSeccomp: false
...
万が一、seccomp がデフォルトでブロックするシステムコールを一部のワークロードで実行する必要がある場合、クラスタ全体で seccomp を無効にする必要はありません。代わりに、特定のワークロードを選んで unconfined mode で実行できます。unconfined mode でワークロードを実行すると、seccomp プロファイルがクラスタの残りの部分に適用する制限からそのワークロードが解放されます。
unconfined mode でコンテナを実行するには、次の securityContext セクションを Pod マニフェストに追加します。
apiVersion: v1
kind: Pod
....
spec:
securityContext:
seccompProfile:
type: Unconfined
....
root ユーザーとしてコンテナを実行しない
デフォルトでは、コンテナ内のプロセスは root として実行されます。プロセスがコンテナから抜け出した場合、そのプロセスはホストマシン上で root として実行されるため、セキュリティ上の問題になる可能性があります。したがって、すべてのワークロードを非 root ユーザーとして実行することをおすすめします。
以降のセクションでは、コンテナを非 root ユーザーとして実行する 2 つの方法について説明します。
メソッド #1: Dockerfile に USER 命令を追加する
このメソッドは Dockerfile を使用して、コンテナが root ユーザーとして実行されないようにします。Dockerfile では、コンテナ内のプロセスを実行するユーザーを指定できます。以下の Dockerfile のスニペットは、これを行う方法を示しています。
....
#Add a user with userid 8877 and name nonroot
RUN useradd −u 8877 nonroot
#Run Container as nonroot
USER nonroot
....
この例では、Linux コマンド useradd -u によって、コンテナ内に nonroot というユーザーが作成されます。このユーザーには、8877 というユーザー ID（UID）が割り当てられます。
Dockerfile の次の行によって、コマンド USER nonroot が実行されます。このコマンドでは、イメージのこの時点以降に対してそのように実行するように指定され、ユーザー nonroot としてコマンドが実行されます。
コンテナ プロセスを nonroot に対して正しく実行できるように、UID 8877 に権限を付与します。
メソッド #2: Kubernetes マニフェスト ファイルに securityContext フィールドを追加する
この方法では、コンテナが root ユーザーとして実行されないように Kubernetes マニフェスト ファイルを使用します。Pod にはセキュリティ設定が指定されており、それらのセキュリティ設定は Pod 内のすべてのコンテナに適用されます。
次の例は、特定の Pod のマニフェスト ファイルから抜粋した内容を示しています。
apiVersion: v1
kind: Pod
metadata:
name: name-of-pod
spec:
securityContext:
runAsUser: 8877
runAsGroup: 8877
....
runAsUser フィールドは、Pod 内のコンテナに対して、すべてのプロセスがユーザー ID 8877 で実行されることを指定します。runAsGroup フィールドは、これらのプロセスのプライマリ グループ ID（GID）が 8877 であることを指定します。コンテナ プロセスを適切に実行できるように、UID 8877 に必要かつ十分な権限を付与してください。
これにより、コンテナ内のプロセスが root よりも権限が少ない UID 8877 として実行されるようになります。
GKE on Bare Metal のシステム コンテナは、クラスタのインストールと管理に役立ちます。これらのコンテナで使用される UID と GID は、クラスタ仕様のフィールド startUIDRangeRootlessContainers で制御できます。startUIDRangeRootlessContainers はオプションのフィールドで、指定しない場合、2000 の値が設定されます。startUIDRangeRootlessContainers に指定できる値は 1000～57000 です。startUIDRangeRootlessContainers 値はアップグレード時にのみ変更できます。システム コンテナは、startUIDRangeRootlessContainers～startUIDRangeRootlessContainers + 2999 の範囲の UID と GID を使用します。
次の例では、クラスタのマニフェスト ファイルの一部を示します。
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: name-of-cluster
spec:
clusterSecurity:
startUIDRangeRootlessContainers: 5000
...
startUIDRangeRootlessContainers の値は、システム コンテナで使用される UID と GID のスペースが、ユーザー ワークロードに割り当てられた UID と GID のスペースと重複しないように選択する必要があります。
ルートレス モードを無効にする方法
GKE on Bare Metal のリリース 1.10 以降では、Kubernetes コントロール プレーン コンテナとシステム コンテナは、デフォルトで root 以外のユーザーとして実行されます。GKE on Bare Metal は、これらのユーザーに 2000～4999 の範囲の UID と GID を割り当てます。ただし、この UID と GID が環境内で実行されるプロセスにすでに割り当てられている場合は、このアサインメントによって問題が発生する可能性があります。
GKE on Bare Metal のリリース 1.11 では、クラスタをアップグレードするときにルートレス モードを無効にできます。rootless モードを無効にすると、Kubernetes コントロール プレーン コンテナとシステム コンテナは root ユーザーとして実行されます。
rootless モードを無効にするには、次の手順を行います。
次の
clusterSecurityセクションをクラスタの構成ファイルに追加します。apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: example namespace: cluster-example spec: ... clusterSecurity: enableRootlessContainers: false ...クラスタをアップグレードします。詳細については、クラスタをアップグレードするをご覧ください。
ワークロードの自己変更機能を制限する
特定の Kubernetes ワークロード（特にシステム ワークロード）には、自己変更の権限があります。たとえば、一部のワークロードは垂直方向に自動スケーリングされます。これは便利ですが、すでにノードを不正使用した攻撃者がクラスタ内でさらにエスカレーションする可能性があります。たとえば、攻撃者がノード上のワークロード自体を変更して、同じ名前空間内に存在する、より権限の高いサービス アカウントとして実行するおそれがあります。
理想的には、ワークロードにはそもそも自己変更機能を付与するべきではありません。自己変更が必要な場合は、オープンソースの Gatekeeper ライブラリから NoUpdateServiceAccount などの Gatekeeper またはポリシー コントローラの制約を適用して権限を制限できます。これにより、いくつかの有用なセキュリティ ポリシーが提供されます。
ポリシーをデプロイする場合、通常はクラスタのライフサイクルを管理するコントローラがポリシーをバイパスできるようにする必要があります。これは、コントローラがクラスタに変更を加える（クラスタのアップグレードを適用するなど）ことができるようにするために必要です。たとえば、GKE on Bare Metal に NoUpdateServiceAccount ポリシーをデプロイする場合は、Constraint で次のパラメータを設定する必要があります。
parameters:
allowedGroups:
- system:masters
allowedUsers: []
kubelet 読み取り専用ポートを無効にする
リリース 1.15.0 以降、GKE on Bare Metal では、デフォルトで 10255 の kubelet 読み取り専用ポートが無効化されます。お客様のワークロードが、この安全でない kubelet ポート 10255 からデータを読み取るように構成されている場合は、安全な kubelet ポート 10250 を使用するように移行する必要があります。
このポートは、バージョン 1.15.0 以降で作成されたクラスタしかデフォルトで無効になっていません。クラスタがバージョン 1.15.0 以降にアップグレードされても、1.15.0 より前のバージョンで作成されたクラスタでは、kubelet 読み取り専用ポート 10255 がアクセス可能なまま残ります。
この変更は、機密性の低い情報が kubelet が未認証のポート 10255 を介して漏洩したことから加えられたものです。この情報には、ノード上で実行されているすべての Pod の完全な構成情報が含まれており、攻撃者にとって貴重な情報となる可能性があります。また、指標やステータス情報も公開され、ビジネス上重要な分析情報を含んでいる可能性があります。
CIS Kubernetes Benchmark では、kubelet 読み取り専用ポートを無効にすることが推奨されています。バージョン 1.14 でポートを手動で無効にするには、kubelet 読み取り専用ポートを無効にするをご覧ください。
メンテナンス
セキュリティ情報のモニタリングとクラスタのアップグレードは、クラスタが稼働した後に実施する必要がある重要なセキュリティ対策です。
セキュリティ情報を監視する
GKE Enterprise セキュリティ チームは、重大度が「高」や「重大」の脆弱性のセキュリティに関する公開情報を公表しています。
これらの情報は、共通の Google Cloud 脆弱性番号スキームに従っており、Google Cloud 情報のメインページと GKE on Bare Metal のリリースノートからリンクされています。この XML フィードを使用して、GKE on Bare Metal と関連プロダクトのセキュリティに関する公開情報を定期的に受け取ります。https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml 
このような重大度が「高」や「重大」の脆弱性に対処するためにお客様の対応が必要な場合は、Google からメールでご連絡いたします。また、Google はサポート チャネルを通じてサポート契約を結んでいるお客様にご連絡する場合もあります。
GKE と GKE Enterprise のセキュリティの脆弱性とパッチの Google での管理方法については、セキュリティ パッチをご覧ください。
クラスタをアップグレードする
Kubernetes では新しいセキュリティ機能が定期的に導入されており、セキュリティ パッチが提供されています。GKE on Bare Metal のリリースには、クラスタに影響を与える可能性があるセキュリティの脆弱性に対処する Kubernetes セキュリティ強化が組み込まれています。
GKE クラスタを最新の状態に保つことは、はユーザーの責任です。各リリースについて、リリースノートをご確認ください。GKE クラスタのセキュリティ リスクを最小限に抑えるには、新しいパッチリリースへの更新を毎月、マイナー バージョンへの更新を 3 か月ごとに実施するようにしてください。
クラスタのアップグレードのメリットの 1 つは、クラスタの kubeconfig ファイルが自動的に更新されることです。kubeconfig ファイルは、クラスタに対してユーザーを認証します。bmctl でクラスタを作成すると、kubeconfig ファイルはクラスタ ディレクトリに追加されます。デフォルトの名前とパスは bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig です。クラスタをアップグレードすると、そのクラスタの kubeconfig ファイルが自動的に更新されます。それ以外の場合、kubeconfig ファイルは作成日から 1 年後に期限切れになります。
クラスタのアップグレード方法については、クラスタをアップグレードするをご覧ください。