ブログ

k8s-security-configwatchを利用したGitOpsセキュリティ

k8s-security-configwatchを利用したGitOpsセキュリティ

本文の内容は、2020年3月5日にSysdigのKaizhe Huangが投稿したブログ(https://sysdig.com/blog/gitops-k8s-security-configwatch/)を元に日本語に翻訳・再構成した内容となっております。

Sysdigのオープンソースツールであるk8s-security-configwatch GitHub Actionは、Kubernetesセキュリティ構成の変更を検出することでGitOpsワークロードを保護します。

このようなシナリオを想像してみてください。「Kubernetes Swag」ストアのSecure DevOpsチームは、セキュリティアラームの調査に熱中しています。彼らのKubernetesコンテナは侵害され続けています。 危機が始まって1時間後、チームメンバーはポッドの構成を見て、「見つけました!」と叫びます。 ネットワーク構成が台無しになり、コンテナが公開され、攻撃者はこのセキュリティ侵害を悪用しています。チームのインターンの顔が赤くなりました。 彼は数時間前にいくつかの設定変更を適用しましたが、おそらく設定エラーの原因は彼です。

これはどうして可能だったのでしょうか? 誰かがクラスター構成の変更を見ていなかったのでしょうか?

この画像のalt属性が入力されていません

GitOpsは、上記のようなシナリオを防ぎ、設定をgitリポジトリに配置し、プルリクエスト(PR)を介して変更のレビューを強制することを目的としています。 K8s-security-configwatchはGitHubアクションであり、構成変更のセキュリティへの影響を確認し、GitOpsにセキュリティを組み込みます。

Gitopsの概要

GitOpsは、コード原則としてインフラストラクチャに従ってKubernetesクラスター管理とアプリケーション配信を行う方法です。Gitを単一の真実のソースとして使用し、インフラストラクチャとアプリケーションの宣言を保存します。gitリポジトリの構成またはコードの変更はKubernetesクラスターに簡単に適用でき、クラスターで直接行われた変更も簡単に修正できます。

Gitがデリバリーパイプラインの中心にあるため、変更があると監査証跡が残ります。ただし、最も重要なことは、不適切な構成が実稼働環境に到達するのを防ぐためにレビュープロセスを導入できることです。

開発者は、プルリクエスト(PR)を介してこれらの変更をリクエストできます。次に、複数のチームメイトがそれらをレビューし、必要に応じて変更と説明を要求します。変更が承認されて初めて、変更がクラスターにデプロイされます。

20200306-1.png

ただし、このシステムは完全ではなく、いくつかの潜在的な問題があります。

  1. 適切なレビュアーがプルリクエストに割り当てられていない場合はどうるでしょうか?
  2. レビュー担当者はまだいくつかの構成変更を見逃す可能性があり、権限昇格につながります。

これは、Sysdigの新しいオープンソースツールであるk8s-security-configwatchがその価値を示す場所です。K8s-security-configwatchは、Kubernetes構成ファイルの変更を確認するGithubアクションで、クラスターのセキュリティに影響を与える可能性のある変更を強調表示します。レビューアは、それらの領域に特別な注意を払い、正しい目ですべてのプルリクエストを検証していることを確認できます。

Github Actionの概要

GitHubアクションは、GitHubリポジトリからソフトウェア開発ワークフローを自動化するのに役立ちます。 アクションと呼ばれる個々のタスクを記述し、それらを組み合わせて複雑なワークフローを作成できます。

ワークフローの例としては、CI/CDパイプラインがあります。このパイプラインでは、リポジトリでのコミットがプロジェクトのビルド、テストの実行、セキュリティの脅威のスキャン、さらには運用環境へのデプロイメントをトリガーします。

20200306-2.png

k8s-security-configwatchの場合、次のワークフローの一部にする事ができます。プルリクエストがワークフローをトリガーし、k8s-security-configwatchがコードを分析します。PRのコード変更がセキュリティに影響を与える場合、セキュリティエンジニアがレビューアとして自動的に追加されます。

20200306-3.png

k8s-security-configwatchはどのような変更を追跡しますか?

K8s-security-configwatchは、Kubernetes SecurityContextオブジェクト、PodSecurityContextオブジェクト、およびhost namespace設定で行われた変更を検出します。これは、Kubernetesワークロードに関連するセキュリティ属性の大部分をカバーしています。K8s-security-configwatchが追跡する属性の完全なリストは次のとおりです。

  • privileged
  • HostPID
  • HostIPC
  • HostNetwork
  • capabilities
  • ReadOnlyRootFileSystem
  • RunAsUser (root/non-root)
  • RunAsGroup (root/non-root)
  • volume types

これらの属性ごとに、K8s-security-configwatchは次のフィードバックを提供します。

  • no change: 属性が同じ場合
  • escalated: 属性がセキュリティを緩和した場合。 これにより、セキュリティギャップが生じる可能性があります
  • reduced: 属性がより制限された場合。これにより、アプリケーションがフェイルする可能性があります

設定ファイルでこれらの属性の例を見てみましょう。 以下はポッドのSecurityContextです。

apiVersion: v1
kind: Pod
metadata:
  name: packetbeat-pod
  labels:
    app: packetbeat
spec:
  containers:
  - name: packetbeat
    image: elastic/packetbeat:7.6.0
    securityContext:
      privileged: false
      capabilities:
        add:
        - NET_ADMIN
  hostNetwork: true 

ここで、packetbeat-podはhost network namespaceにアクセスできます。 ポッド内のpacketbeatコンテナにも、NET_ADMIN機能が追加されています。これらの属性はすべて、ほとんどのポッドでアラームをトリガーする必要がありますが、この場合、ネットワーク監視タスクを実行するためにpacketbeatがそれらを必要とするため、それらは問題ありません。

K8s-security-configwatchをGithubアクションワークフローに統合する

K8s-security-configwatchはGitHubアクションであり、Github Marketplaceで見つけることができます。次の例の手順を、プルリクエストによってトリガーされるGithubアクションワークフローに追加して、k8s-security-configwatchを統合できます。Githubアクションワークフローの作成に関するヒントが必要な場合は、Githubアクションを使用したイメージスキャンの記事をご覧ください。

# checkout master branch
- uses: actions/checkout@v2
    with:
      ref: master
      path: master
# checkout PR branch
- uses: actions/checkout@v2
    with:
      ref: ${{ github.event.pull_request.head.sha }}
      path: candidate
# pass the yamls directory to k8s-privilege-check git action
- name: Kubernetes Security configwatch
  uses: sysdiglabs/k8s-security-configwatch@v1.0.0
  with:
    sourceDir: '/master/yamls'
    targetDir: '/candidate/yamls'
# evaluate escalation report
- name: Post Privilege Check
  run: |
    echo ${{ toJSON(steps.k8s_privilege_check.outputs.escalation_report) }}
    # slack
    # or other git action like adding another reviewer
    # or send configwatch result to Sysdig Monitor 

手順を1つずつ確認しましょう。

最初のステップは、リファレンスブランチ(この場合はマスターブランチ)からソースコードをダウンロードすることです。ソースコードは、masterというフォルダーにダウンロードされます。

# checkout master branch
- uses: actions/checkout@v2
    with:
      ref: master
      path: master 

次のステップは、変更を含むブランチからソースコードをダウンロードすることです。 ソースコードは、candidateと呼ばれるフォルダーにダウンロードされます。

# checkout PR branch
- uses: actions/checkout@v2
    with:
      ref: ${{ github.event.pull_request.head.sha }}
      path: candidate 

これで、k8s-security-configwatchを使用して、これら2つのフォルダーのコードを比較できます。

# pass the yamls directory to k8s-privilege-check git action
- name: Kubernetes Security configwatch
  uses: sysdiglabs/k8s-security-configwatch@v1.0.0
  with:
    sourceDir: '/master/yamls'
    targetDir: '/candidate/yamls' 

内部では、k8s-security-configwatchはSysdigオープンソースツールkube-psp-advisorを使用して比較を実行します。 kube-psp-advisorを使用したKubernetesポッドセキュリティの有効化に関する記事では、このツールを紹介し、Kubernetesクラスタのアダプティブポッドセキュリティポリシーの生成に役立つ方法について説明しています。

k8s-security-configwatchからの出力は、escalation_report属性の下のconfigwatchレポートになります。 次に何をするかはあなた次第です。

# evaluate escalation report
- name: Post Privilege Check
  run: |
    echo ${{ toJSON(steps.k8s_privilege_check.outputs.escalation_report) }} 

レポートを解析し、1つのセキュリティ属性が更新された場合にアクションを実行することを決定できます。たとえば、Slackチャネルにメッセージを送信したり、プルリクエストのレビューアーとしてセキュリティエンジニアを自動的に追加したりします。

また、Sysdig Monitorでこの問題をイベントとして提起することもできます。この場合、Kubernetesクラスターメトリクス、ヘルスステータス、イベントなどを一元的に追跡することもできます。Sysdig Monitorで生成されるレポートは次のようになります。

20200306-4.png

まとめ

設定の変更は、アプリケーションコードと同じ方法で監査する必要があります。GitOpsは、コードの原則としてインフラストラクチャに従っており、その目標を達成するためのツールを構築するのに役立ちます。Githubアクションk8s-security-configwatchはKubernetesのセキュリティ変更を検出し、GitOpsワークロードを保護します。

Sysdig SecureのKubernetes Policy Advisorは、ポッドセキュリティポリシーの生成を自動化し、デプロイメント前にそれらを検証して、適用時にアプリケーションを危険にさらさないようにします。

より詳しく知りたい方は、https://sysdig.jp/を是非参照ください。試されたい方は、https://sysdig.jp/ 内の無料お試しをクリックすると14日間のトライアルライセンスが発行されます。

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top