このドキュメントでは、ベアメタル版 Anthos クラスタのセキュリティを強化する方法について説明します。
SELinux を使用してコンテナを保護する
Red Hat Enterprise Linux（RHEL）と CentOS でサポートされている SELinux を有効にすることで、コンテナを保護できます。ホストマシンが RHEL または CentOS を実行している場合で、クラスタで SELinux を有効にするには、すべてのホストマシンで SELinux を有効にする必要があります。詳細については、SELinux を使用してコンテナを保護するをご覧ください。
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 は、ユーザー ワークロードに権限を割り当てるときに使用します。
ワークロードの自己変更機能を制限する
特定の 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 年後に期限切れになります。
クラスタのアップグレード方法については、クラスタをアップグレードするをご覧ください。