このドキュメントでは、ベアメタル版 Anthos クラスタのセキュリティを強化する方法について説明します。
SELinux を使用してコンテナを保護する
Red Hat Enterprise Linux（RHEL）と CentOS でサポートされている SELinux を有効にすることで、コンテナを保護できます。ホストマシンが RHEL または CentOS を実行している場合で、クラスタで SELinux を有効にするには、すべてのホストマシンで SELinux を有効にする必要があります。詳細については、SELinux を使用してコンテナを保護するをご覧ください。
seccomp を使用してコンテナを制限する
セキュア コンピューティング モード（seccomp）は、Anthos clusters on bare metal のバージョン 1.11 で利用できます。seccomp プロファイルを使用してコンテナを実行すると、コンテナがカーネルに対して実行できるシステム呼び出しが制限されるため、クラスタのセキュリティが向上します。これにより、カーネルの脆弱性が悪用される可能性が低くなります。
デフォルトの seccomp プロファイルには、コンテナが実行できるシステムコールのリストが含まれています。リストにないシステム呼び出しは許可されません。Anthos clusters 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 として実行されるようになります。
ベアメタル版 Anthos クラスタのシステム コンテナはクラスタのインストールと管理に役立ちます。また、2000～4999 の範囲の UID と GID を持ちます。そのため、この予約済み範囲外の UID と GID は、ユーザー ワークロードに権限を割り当てるときに使用します。
ルートレス モードを無効にする方法
Anthos clusters on Bare Metal のリリース 1.10 以降では、Kubernetes コントロール プレーン コンテナとシステム コンテナは、デフォルトで root 以外のユーザーとして実行されます。Anthos clusters on Bare Metal は、これらのユーザーに 2000～4999 の範囲の UID と GID を割り当てます。ただし、この UID と GID が環境内で実行されるプロセスにすでに割り当てられている場合は、このアサインメントによって問題が発生する可能性があります。
Anthos clusters on bare metal のリリース 1.11 では、クラスタをアップグレードするときにルートレス モードを無効にできます。ルートレス モードが無効になっていると、Kubernetes コントロール プレーン コンテナとシステム コンテナが root ユーザーとして実行されます。
ルートレス モードを無効にするには、次の操作を行います。
クラスタの構成ファイルに次の
clusterSecurityセクションを追加します。apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: example namespace: cluster-example spec: ... clusterSecurity: enableRootlessContainers: false ...クラスタをアップグレードします。詳細については、クラスタをアップグレードするをご覧ください。
ワークロードの自己変更機能を制限する
特定の Kubernetes ワークロード（特にシステム ワークロード）には、自己変更の権限があります。たとえば、一部のワークロードは垂直方向に自動スケーリングされます。これは便利ですが、すでにノードを不正使用した攻撃者がクラスタ内でさらにエスカレーションする可能性があります。たとえば、攻撃者がノード上のワークロード自体を変更して、同じ名前空間内に存在する、より権限の高いサービス アカウントとして実行するおそれがあります。
理想的には、ワークロードにはそもそも自己変更機能を付与するべきではありません。自己変更が必要な場合は、オープンソースの Gatekeeper ライブラリから NoUpdateServiceAccount などの Gatekeeper またはポリシー コントローラの制約を適用して権限を制限できます。これにより、いくつかの有用なセキュリティ ポリシーが提供されます。
ポリシーをデプロイする場合、通常はクラスタのライフサイクルを管理するコントローラがポリシーをバイパスできるようにする必要があります。これは、コントローラがクラスタに変更を加える（クラスタのアップグレードを適用するなど）ことができるようにするために必要です。たとえば、ベアメタル版 Anthos クラスタに NoUpdateServiceAccount ポリシーをデプロイする場合は、Constraint で次のパラメータを設定する必要があります。
parameters:
allowedGroups:
- system:masters
allowedUsers: []
メンテナンス
セキュリティ情報のモニタリングとクラスタのアップグレードは、クラスタが稼働した後に実施する必要がある重要なセキュリティ対策です。
セキュリティ情報を監視する
Anthos のセキュリティ チームは、重大度が「高」や「重大」の脆弱性のセキュリティに関する情報を公開しています。
これらの情報は、共通の Google Cloud 脆弱性番号スキームに従っており、Google Cloud 情報のメインページとベアメタル版 Anthos クラスタのリリースノートからリンクされています。この XML フィードを使用して、ベアメタル版 Anthos クラスタおよび関連プロダクトに関するセキュリティ情報を定期的に受け取ります。https://cloud.google.com/feeds/anthos-gke-security-bulletins.xml 
このような重大度が「高」や「重大」の脆弱性に対処するためにお客様の対応が必要な場合は、Google からメールでご連絡いたします。また、Google はサポート チャネルを通じてサポート契約を結んでいるお客様にご連絡する場合もあります。
GKE と Anthos のセキュリティ脆弱性とパッチの Google での管理方法については、セキュリティ パッチをご覧ください。
クラスタをアップグレードする
Kubernetes では新しいセキュリティ機能が定期的に導入されており、セキュリティ パッチが提供されています。ベアメタル版 Anthos クラスタのリリースには、クラスタに影響を与える可能性があるセキュリティの脆弱性に対処する Kubernetes セキュリティ強化が組み込まれています。
Anthos クラスタを最新の状態に保つことは、はユーザーの責任です。各リリースについて、リリースノートをご確認ください。Anthos クラスタのセキュリティ リスクを最小限に抑えるには、新しいパッチリリースへの更新を毎月、マイナー バージョンへの更新を 3 か月ごとに実施するようにしてください。
クラスタのアップグレードのメリットの 1 つは、クラスタの kubeconfig ファイルが自動的に更新されることです。kubeconfig ファイルは、クラスタに対してユーザーを認証します。bmctl でクラスタを作成すると、kubeconfig ファイルはクラスタ ディレクトリに追加されます。デフォルトの名前とパスは bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig です。クラスタをアップグレードすると、そのクラスタの kubeconfig ファイルが自動的に更新されます。それ以外の場合、kubeconfig ファイルは作成日から 1 年後に期限切れになります。
クラスタのアップグレード方法については、クラスタをアップグレードするをご覧ください。