Kubernetes（別名K8s）は、コンテナ化されたワークロードとサービスを管理するためのオープンソース型コンテナオーケストレーションプラットフォームです。コンテナのデプロイメントを担当し、コンテナが相互に通信できるようにするソフトウェア定義ネットワーキング層も管理します。移植性があるプラットフォームで、宣言的な構成と自動化を容易にします。
Kubernetesの公式ウェブサイトでは、「Kubernetesという名前は、操舵手またはパイロットを意味するギリシャ語に由来しています。Googleは、2014 年にKubernetesプロジェクトをオープンソース化しました。Kubernetesは、本番環境で大規模なワークロードを稼働させてきたGoogleの15年以上の経験と、コミュニティで生まれたアイデアや実践を厳選して組み合わせたものです」と説明されています。
Kubernetesは、アプリケーションを実行するさまざまなコンテナをグループ化して管理することにより、コンテナ化されたアプリケーションの規模と複雑さを管理する上で重要な役割を果たします。コンテナは常にスピンアップされて入れ替わるため、ダウンタイムが発生しないよう、Kubernetesがすぐにコンテナを交換します。
ただ、この「コンテナ」とは具体的に何でしょうか。Gartner社の定義によれば、コンテナは、アプリケーションのパッケージ化を簡素化し、アプリケーションの迅速なデプロイメントを可能にするものです。これにより、開発、テスト、ステージング全体でプラットフォームの一貫性が確保され、ビルドとソフトウェアのリリースを加速し、プロセスの再現性を高める上でも役立ちます。
Kubernetesが重要な理由は、コンテナ管理とオーケストレーションを抽象化し、人手での大規模な管理が不可能なタスクを自動化するためです。さまざまな点で、これはDevOpsチームが継続的インテグレーション・継続的デプロイメント（CI/CD）パイプラインのセットアップを行う際の目標を達成する上で、基礎的なコンポーネントとなります。
人間による介入がなくなると、セキュリティリスクが発生します。アナリストは今や、一連の宣言的なポリシーとコマンドに基づいて環境を管理するシステムを信頼しており、これを安全に実行するには、ガードレールを実装し、Kubernetesベースのアプリケーション内で操作を継続的に監視する必要があります。こうすることで、コンプライアンス面での逸脱や異常、不審な行動が確実に捕捉され、対処できるようになります。
そのメリットにより、Kubernetesはたちまち多くのエンタープライズDevOpsチームのオーケストレーションツールのデファクトスタンダードとなりました。このため、AWS、Azure、GCPのようなクラウドサービスプロバイダは、Kubernetesのマネージドバージョン（それぞれEKS、AKS、GKE）をリリースし、kubernetesノードとクラスタの管理・監視の必要性はほぼ排除されました。
DevOpsプロセスにセキュリティを統合する慣行はDevSecOpsとして知られています。開発プロセスへのセキュリティチェックとガードレールの統合は、開発チームがセキュリティとコンプライアンスを犠牲せずに迅速に反復作業を行えるという点でも、本番環境に到達する前に問題を発見できるという点でも、非常に有益です。
Kubernetesの運用においては、セキュリティの確保が複雑なプロセスとなる可能性があります。うまく実行できれば、リスクを高めない方法で開発プロセスを確実に加速できます。Kubernetesの運用でセキュリティのシフトレフトを行う際に表面化しがちな問題をいくつか見てみましょう。
このプロセスでは、アプリケーションのランタイム（本番環境時）を監視して、悪質と考えられるアクティビティをブロックします。ここでの課題は、アラートや脅威の調査結果など、関連する洞察をいかに明らかにできるかにあります。こうした調査結果には、迅速に実行し、自信を持って適切な調査を行うために必要なコンテキストの多くが欠けていることがよくあります。継続的監視のプロセスを自動化すると、DevSecOpsチームの効率は向上しますが、一部の制御を放棄せざるを得なくなり、セキュリティ上の懸念が生じる可能性があります。
小さな誤設定が大きな脆弱性につながる可能性もあります。1つのインスタンスでKubernetesリソースに変更を加えた場合に、それらの変更が追跡されないと、後で変更が上書きされる可能性があります。これにより、セキュリティチェックが正常に機能していても、予期せぬ脆弱性が発生する可能性があります。バージョン管理を行うことで、脆弱性やセキュリティの問題が検出された場合にも、以前の構成状態に迅速に復元することができます。
あらゆる課題の中で最大のものが、Kubernetesコンテナのセキュリティの保護です。当然ながら、このプロセスで発生しうる脆弱性や攻撃を軽減するためのソリューションは市場に多数存在します。複数のコンテナを一度にデプロイする場合、セキュリティの確保が特に難しく、デプロイメントのスケールが拡大することから、複雑さが増す可能性もあります。単一のポリシーフレームワークをすべてのKubernetesワークロードに適用することで、確実にリスクにフラグを立て、クラウドデプロイメントを悪意のある攻撃から保護できます。
レジストリのコンテナイメージを利用するとプロセスを高速化できますが、こうしたイメージには悪意のあるコードが含まれている可能性があります。実際、公開レジストリに存在するKubernetesコンテナを操作する場合には、プロセスへの脆弱性スキャンなどのツールを構築することが欠かせません。
コンテナイメージを非公開で保存し、脆弱性スキャンを活用することで、開発パイプラインが公開のリソースやコンテナイメージにさらされるリスクを最大限に減らせます。また、チームがイメージの脆弱性をすでにデプロイされているコンテナイメージと関連付けるステップを省略した場合は特に、速度が低下する可能性があります。この比較は、ネットワークにもたらされるリスクを理解する上で非常に重要です。
では、Kubernetesの運用を保護する上で最も重要な部分は何でしょうか。
ここまでの説明で、Kubernetesは非常に有益であるものの、慎重かつ系統的に活用する必要があるという重要な事実をご理解いただけたかと思います。そのため、プロセスを学び、立ち上げていく際には、ベストプラクティスをKubernetesワークストリームに統合することが重要です。
RBAC を用いてユーザー アクセス設定します。こうして、サイズや複雑さが増してきても、データやユーザーを効果的に管理できます。製品、ロール、リソースを割り当て、ユーザーが自分のロールに必要な情報にしかアクセスできないようにします。こうすることで、 最小特権の原則が実現し、ユーザーが機密データや関係のない情報にアクセスするのを防ぐことができます。
APは、アプリケーションが相互に行うリクエストの種類、それらのリクエストが行われる方法や形式を制御します。通常、単一のアプリケーションに多くのAPIの使用が組み込まれるため、開発とデプロイメントのプロセスに脆弱性が加わります。このため、APIへのアクセスは絶対に必要とする担当者のみに制限することをお勧めします。
Secure Shell（SSH）は、暗号化セキュリティを使用して開発プロトコルを保護する上で役立ちます。これは本質的に、情報システムを強化されたセキュリティチェックで覆うシェルです。SSHが安全で適切に防御されていない場合、特に公開企業やインターネットに公開されているシステムの場合、クラウドアプリケーションやKubernetesワークロードが脆弱性や攻撃にさらされる可能性があります。
言わずもがなですが、ワークロードとデプロイメントが保護され、適切にコンテナ化されていることを確認するには、Kubernetesを最新の状態に保つことがベストです。実際、Kubernetesにはローリングアップデートプロセスが備わっているため、ユーザーはインスタンスを新しいバージョンで段階的に更新することで、ダウンタイムなしでデプロイメントを更新できます。
脅威のスキャンと監視を継続的に行って対策を講じることで、予期せぬ脆弱性や悪質な脅威から企業を確実に守ることができます。Gartner社が発表した『コンテナワークロード保護プラットフォーム（CWPP）市場ガイド』では、ワークロードがより細分化され、存続期間が短くなっていると記載されています。場合によっては、毎週、または毎日のペースで複数のイテレーションがデプロイされることもあります。
このような急速に変化する短期間のワークロードを保護するには、プロアクティブなアプローチを取り入れることがベストです。デプロイメント前の脆弱性管理と継続的なコードスキャンは、導入時からデプロイメント、ランタイムに至るまで、クラウドベースのワークロードを保護する上で役立ちます。
2022年クラウド誤設定レポート：最新のクラウドセキュリティ侵害と攻撃の傾向