K06:2022 認証メカニズムの不備
Last updated
Last updated
Kubernetes の認証は多くの形態を取り、非常に柔軟です。 このように高度に設定可能であることを重視しているため、Kubernetes は多くのさまざまな環境で動作しますが、クラスタやクラウドセキュリティ体勢に関して課題もあります。
Kubernetes API にアクセスするために必要なエンティティがいくつかあります。 認証はこれらのリクエストの最初のハードルです。 Kubernetes API への認証は HTTP リクエストを介して行われ、認証方式はクラスタごとに異なります。 リクエストが認証できない場合、HTTP ステータス 401 で拒否されます。
Kubernetes API への認証が必要なさまざまなタイプの subject について詳しく見ていきましょう。
人はさまざまな理由で Kubernetes と対話する必要があります。 ステージングクラスタで実行中のアプリケーションをデバッグする開発者や、新しいインフラを構築しテストするプラットフォームエンジニアなど。 OpenID Connect (OIDC)、証明書、クラウド IAM、さらには ServiceAccount トークンなど、人間としてクラスタに認証するために利用できる方法がいくつかあります。 これらの中にはより堅牢なセキュリティを提供するものもあります。 以下の防止方法のセクションで説明します。
サービスアカウント (Service account, SA) トークンは RBAC で適切に設定された場合、認証メカニズムとして Kubernetes API に提示できます。 SA はシンプルな認証メカニズムで、一般的にはクラスタの 内部 からのコンテナから API への認証のために予約されています。
証明書は Kubernetes API への認証に使用すると便利ですが、細心の注意を払って使用すべきです。 現時点では、API には証明書を失効させる方法がないため、秘密鍵マテリアルの侵害や漏洩があった場合、クラスタの鍵を更新するために奔走することになります。 また証明書は設定、署名、配布するのも面倒です。 証明書は "Break Glass" 認証メカニズムとして使用できますが、プライマリ認証には使用してはいけません。
暗号と同様に、必要でないときに新しいものを作るべきではありません。 サポートされ広く採用されているものを使用します。
選ばれた認証メカニズムに関係なく、人間に二番目の認証方式 (通常は OIDC の一部) を提供するように強制します。
すべての認証トークンは許容範囲内で短期間有効であるべきです。 このようにすれば、認証情報が漏洩した場合でも、アカウントを侵害するために必要な時間内にリプレイできない可能性があります。
偶発的な Git 流出: ある開発者が自分のラップトップから誤って .kubeconfig をチェックしてしまいました。 このファイルには稼働中のクラスタの Kubernetes 認証情報が入っていました。 ある人が GitHub をスキャンしてその認証情報を見つけ、ターゲット API (残念ながらインターネット上にあります) にリプレイします。 クラスタは証明書を使用して認証するように設定されているため、流出したファイルにはターゲットクラスタへの認証に成功するために必要なすべての情報が含まれていました。
入手元:
クラスタ内で使用する場合、Kubernetes Service Account トークンは TokenRequest API を使用して直接取得され、投影ボリュームを使用して Pod にマウントされます。 クラスタ外で使用する場合、これらのトークンは を介して手動でプロビジョンする必要があり、有効期限はありません。 クラスタ外から有効期間の長い SA トークンを使用すると、クラスタを重大なリスクにさらすことになります。
トークンベースのアプローチが必要な場合は、 または 使用して、有効期間の短いトークンをプロビジョンできます。
Tremlo Blog Post:
Kubernetes Authentication:
