での Kubernetes 監査の構成ガイドPrisma SaaS.
Symptom
- を参照してください。 Kubernetes の監査ドキュメンテーション
- " に移動します。を構成しますAPIサーバ提供されている手順を参照するには、監査 webhook バックエンドを構成します
- Compute Console で次の場所に移動します。防御 > アクセス > Kubernetes >設定に移動
- コンソールで、「設定に移動" 設定に必要な Webhook URL を検索するオプションを選択すると、設定が空になり、そこに Webhook URL が存在しません。 説明については、以下の画像を参照してください。
Environment
- Prisma Cloud コンピューティング (SaaS 展開)
- Kubernetes (Google Kubernetes エンジン)
- Kubernetes (エラスティック Kubernetes サービスおよび Azure Kubernetes サービス)
Cause
- によるのリリースノートPrisma Cloudコンピューティング バージョン 21.08.514
- Kubernetes 1.19 で廃止された Kubernetes 動的監査構成のサポートを削除します。 動的監査構成は以前に使用されていましたPrisma CloudKubernetes の監査。 Prisma CloudKubernetes の監査今は通常の Webhook バックエンド.
Resolution
Kubernetes 監査を構成する手順は次のとおりです。
次の情報が必要です
- コンソールへのパス'URL (コンピューティング / 管理 / システム / ユーティリティ)
- コンソールのエクスポート=APIトークン (計算 / 管理 / システム / ユーティリティ)
- トークンのエクスポート= <APIトークン>
- 次のユーティリティをインストールする必要があります。
- カール
- jq
- openssl
- kubectl
- ファイアフォックス
- A kube-apiserver マニフェストを更新するためにサポートされている方法。 これは通常、マスター ノードで /etc/kubernetes/manifests/kube-apiserver.manifest を編集することによって行われますが、Linux/K8s ディストリビューションに依存する場合があります。
TASK FLOW:
- で Kubernetes 監査が有効になっていることを確認します。Prisma Cloudコンピューティング
- Webhook を生成する URL
- 証明書チェーンをダウンロードしてbase64に変換
- audit-webhook.yaml を生成します
- ウェブフックを追加し、policyすべてのマスターノードへの構成
- すべてのマスター ノードで kube-apiserver マニフェストを更新する
- セットアップが正しく機能しているかどうかを確認するためのテスト
ステップ 1: で Kubernetes 監査が有効になっていることを確認するPrisma Cloud計算します。
Compute / Access / Kubernetes をブラウズし、Kubernetes 監査が有効になっており、テストするルールがあることを確認します (実行またはポッドへの接続が最も簡単です)。
ステップ 2: Webhook を生成するURL
Webhook を生成するにはURL、webhook サフィックスを生成し、それを「/api/v1/kubernetes/webhook/」エンドポイントに追加する必要があります
次のコマンドを実行して、webhook 変数を作成します。 :
ステップ 3: 証明書チェーンをダウンロードして base64 に変換する
証明書チェーンをダウンロードし、base64 にエクスポートします
- Firefox を開き、「コンソールへのパス」を参照します。 URL
- 証明書アイコンをクリックしてから、ツールバーの接続の安全な矢印をクリックします。
- 詳細情報をクリックします
- [証明書を表示] をクリックします
- [その他] まで下にスクロールして、PEM鎖
- 端末で、cd でフォルダーに移動します。PEMチェーンがダウンロードされました。
- 次のコマンドを実行して、PEM base64 でエンコードされた変数としてのチェーン:
export cacerts=$(openssl base64 -in cloud-twistlock-com-chain.pem -A)
ステップ 4: audit-webhook.yaml を生成する
audit-webhook.yaml と audit- を生成しますpolicy監査イベントを送信するために必要な .yaml ファイル Prisma Cloud
- 次のコマンドを実行して、audit-webhook.yaml を生成します。
cat <<EOF > audit-webhook.yaml apiVersion: v1 kind: Config preferences: {} clusters: - name: audit-cluster cluster: server: $webhookurl certificate-authority-data: $cacerts contexts: - name: webhook context: cluster: audit-cluster user: kube-apiserver current-context: webhook EOF
- 次のコマンドを実行して、デフォルトの監査を生成しますpolicy:
cat <<EOF > audit-policy.yaml apiVersion: audit.k8s.io/v1 # This is required. kind: Policy # Generate audit events only for ResponseComplete or panic stages of a request. omitStages: - "RequestReceived" - "ResponseStarted" rules: # Audit on pod exec/attach events - level: Request resources: - group: "" resources: ["pods/exec", "pods/attach"] # Audit on pod creation events - level: Request resources: - group: "" resources: ["pods"] verbs: ["create"] # Audit on changes to the twistlock namespace (defender daemonset) - level: Request verbs: ["create", "update", "patch", "delete"] namespaces: ["twistlock"] # Default catch all rule - level: None EOF
ステップ 5: Webhook を追加し、policyすべてのマスターノードへの構成
次に、kube-apiserver からアクセス可能なファイル内のすべてのマスター ノードに監査ファイルを追加する必要があります。
- 次のコマンドを実行して、kube-apiserver にアクセスできるホスト ボリュームを表示します。
kubectl get pods -n kube-system kube-apiserver-<rest of pod name> -o jsonpath='{range .spec.volumes[*]}{.hostPath.path}{"\n"}{end}'
- 配置するのに最も適したパスを書き留めます。YAML以前に生成されたファイル。 たとえば、これは次のパスを返しました。
/var/log/kube-apiserver.log /etc/ssl /etc/pki/tls /etc/pki/ca-trust /usr/share/ssl /usr/ssl /usr/lib/ssl /usr/local/openssl /var/ssl /etc/openssl /etc/kubernetes/in-tree-cloud.config /srv/kubernetes/ca.crt /srv/kubernetes/kube-apiserver /srv/sshproxy /etc/kubernetes/kube-apiserver-healthcheck/secrets
I /srv/kubernetes/kube-apiserver パスが私にとって最も理にかなっていると判断しました。
- SCP audit-webhook.yaml および audit-policy .yaml を、選択したパス (私の場合は /srv/kubernetes/kube-apiserver) 内の各マスター ノードに転送します。
ステップ 6: すべてのマスター ノードで kube-apiserver マニフェストを更新する
この手順は k8s ディストリビューションによって異なるため、先に進む前に、これが適切な方法であることをベンダー/ドキュメントで確認してください。
- kube-apiserver.manifest ファイルを見つけます
- テキスト エディターで kube-apiserver.manifest を開き、次のようなセクションを見つけます。
spec: containers: - command: - kube-apiserver - --admission-control-config-file=/etc/kubernetes/extra-config/admission-control-config.yaml - --advertise-address=X.X.X.X - --allow-privileged=true - --audit-log-maxage=30 - --audit-log-maxbackup=10 - --audit-log-maxsize=100 - --audit-log-path=/var/log/kubernetes/kube-apiserver.log
- コマンド リストの「-kube-apiserver」の下に次のオプションを追加し、赤色のパスを前に選択したパスに更新してください。
--audit-policy-file=/srv/kubernetes/kube-apiserver/audit-policy.yaml --audit-webhook-config-file=/srv/kubernetes/kube-apiserver/audit-webhook.yaml
- 完了すると、更新 kube-apiserver.manifest は次のようになります。
spec: containers: - command: - kube-apiserver - --admission-control-config-file=/etc/kubernetes/extra-config/admission-control-config.yaml - --advertise-address=X.X.X.X - --allow-privileged=true - --audit-log-maxage=30 - --audit-log-maxbackup=10 - --audit-log-maxsize=100 - --audit-policy-file=/srv/kubernetes/kube-apiserver/audit-policy.yaml - --audit-webhook-config-file=/srv/kubernetes/kube-apiserver/audit-webhook.yaml - --audit-log-path=/var/log/kubernetes/kube-apiserver.log
- 注: kube-apiserver マニフェスト ファイルMUST監査ログを有効にするには、audit-log-path オプションを有効にします。
- マニフェスト ファイルを保存すると、kube-apiserver が再起動します。これには約 30 秒かかり、一時的にアクセスできなくなる場合があります。API .
デフォルト ルールの 1 つに対してテストを実行し、それが機能していることを確認します。
- コンテナ内で exec を実行して、デフォルト ルールの 1 つをテストします。
kubectl exec <pod> -it -- /bin/sh
- を確認してくださいPrisma CloudCompute / Monitor / Events / Kubernetes Audits のコンソール
Additional Information
トラブルシューティング
kube-apiserver ポッドがバックアップを開始できない場合は、通常、マニフェスト ファイルに問題があることを意味します。 これをトラブルシューティングする必要がありますが、プロセスは kubernetes ディストリビューションに依存します。 A いくつかの可能な方法は次のとおりです。
- journalctl --unit kubelet
- docker ログ <コンテナ>
- crictl ログ <コンテナ>
もしPrisma Cloudコンソールは監査ログを表示できません。通常、kube-apiserver ログから手がかりが得られます。
- kubectl は kube-apiserver-<ポッド名の残り> をログに記録します
関連情報