ocm-mcp-server

ocm-mcp-server

📖 ドキュメントサイトを読む → ocm-mcp-server.github.io

スターをお願いします ❤️ → 

### Kubernetes フリート向けの安全な AgentOps。

Open Cluster Management（OCM）](https://open-cluster-management.io/) ハブを介して、AI エージェントがマルチクラスター Kubernetes フリートを操作できる MCP サーバーです。モデルとクラスターの間にポリシー、承認、監査を設けます。

エージェントが kubeconfig を保持することはありません。すべての書き込みはポリシーでチェックされ、人間の承認を受け、追跡されます。

📦 入手する  ·  ✨ なぜこれが必要なのか  ·  🔌 エージェントを接続する  ·  🧭 アーキテクチャ  ·  🧰 ツールセット  ·  🛠️ ツール  ·  💬 プロンプト  ·  🔭 可観測性  ·  🚀 クイックスタート  ·  📖 Wiki  ·  📚 ドキュメント

_{安全な修復の一連の流れ：無料の読み取りで調査し、変更案を提示して、ガードレールに却下されたら修正します。人間が署名したトークンを待ってから適用し、確認したうえで、監査ログからレポートを作成します。}

入手方法と審査について

• 📦 PyPI - ocm-mcp-server - pip install ocm-mcp-server （または uvx ocm-mcp-server で直接実行できます）。すべてのリリースは OIDC trusted publishing により CI から直接公開されます。長期間有効なトークンは一切使用しません。
• 🗂️ 公式 MCP レジストリ - io.github.ocm-mcp-server/ocm-mcp-server として登録されているため、レジストリを参照するあらゆる MCP クライアントやプラットフォームでこのサーバーを検出し、自動設定できます（パッケージ、トランスポート、必須の環境変数はすべて登録情報に含まれています）。レジストリは、このリポジトリと PyPI パッケージに照らして登録情報を検証します。
• 🐳 GHCR のコンテナーイメージ - docker run ghcr.io/ocm-mcp-server/ocm-mcp-server（kubeconfig のマウント方法は デプロイガイドを参照してください）。CI でビルドされ、SBOM と SLSA 来歴が付与されています。Trivy による脆弱性チェックを通過し、Cosign で鍵なし署名されているため、実行するものを検証できます。
• 🛡️ OpenSSF Scorecard - リポジトリのサプライチェーンセキュリティ対策（依存関係の固定、ブランチ保護、署名付きリリースなど）は毎週自動的に評価され、誰でも確認できるよう公開されています。

これが必要な理由

チームでは多数の Kubernetes クラスターを運用しています。遅かれ早かれ、誰かがこう尋ねます。 午前 2 時の緊急対応を AI エージェントに任せられるだろうか？

一番手っ取り早く確かめる方法は、クラスター管理者権限を持つ kubectl をモデルに渡して様子を見ることです。 本番環境でその実験を行うと、3 つの理由から悪い結果になります。

• モデルの動作は非決定的です。 同じアラートでも、ある実行では慎重に診断する一方で、次の実行では kubectl delete を実行する可能性があります。
• 認証情報は本物です。 モデルの判断と本番クラスターの間に、ドライランはありません。
• 記録が残りません。 何か問題が起きても、エージェントが何を、どの順番で、誰の権限に基づいて行ったかを再現できません。

このプロジェクトは、別の見方から出発しています。すでにフリートには、人々が日々信頼している制御点、つまりマルチクラスターのハブがあります。Open Cluster Management（CNCF プロジェクト）は、すべてのフリートにインベントリー（ManagedCluster）、スケジューラー（Placement）、配信チャネル（ManifestWork）を提供します。ocm-mcp-server はこのハブを、型付きの MCP ツールの小さなセットとしてエージェントに公開し、モデルとクラスターの間に独立した 4 つのレイヤーを設けます。

これらのレイヤーはどれもシステムプロンプトに含まれていないため、説得によって覆すことはできません。

_{書き込みは、人を間に挟んだ2回の呼び出しで行います。トークンは1つのコンテンツハッシュと1つの操作に紐付けられ、自動的に期限切れとなり、2回目に提示されると拒否されます。}

_{2つの書き込み、同じ4つの関門。特権付きでピン留めされていないものはレイヤー 1で拒否され、クラスターに到達しません。要件を満たすものは、人間が正確なコンテンツに署名するまで待機し、その後適用されて検証されます。}

_{Claude と過ごすフリート運用担当者の1日を、クリーンな状態からライブで紹介します。PyPI からインストールし、claude mcp add を実行して、フリートをインベントリし、配置を判断します。そしてゲートを設けた方法で新しいサービスをデプロイします。特権付きの :latest による近道は拒否され、ピン留めされたプロポーザルは人間が署名し、トークンで適用されて検証され、1日の全行程が監査証跡から読み戻されます。 — ナレーション付き MP4 · ターミナル録画。}

_{同じ1日を、4種類のエージェントで実行。10の章は同じで、サーバーも同じです。変わるのは呼び出すエージェントだけで、これこそクライアントを提供するのではなく MCP で連携する理由です。Codex · Gemini (Antigravity CLI)。hack/demo-record.sh all を使って、いずれも再録画できます。}

サーバーは標準の MCP over stdio で通信するため、特定のベンダーのエージェントに依存するものはありません。 この主張は言葉だけでなく、実際に実証されています。同じ 10 章のオペレーターセッションを、 Claude Code、Codex、Antigravity CLI 経由の Gemini、IBM Bob Shell という4 種類のエージェントで 記録しています。それぞれが同じフリートに対して同じサーバーを操作し、実際にツールを呼び出し、 ガードレールによる拒否に遭遇し、人間が署名したトークンを使った場合に限って変更を適用します。 hack/demo-record.sh all で、いずれのセッションも再記録できます。

すぐに使える設定は examples/ にあります。各ファイルの配置場所はインデックスを確認してください。

{
  "mcpServers": {
    "ocm-fleet": {
      "command": "ocm-mcp-server",
      "env": {
        "OCM_MCP_HUB_CONTEXT": "kind-hub",
        "OCM_MCP_SPOKE_CONTEXTS": "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"
      }
    }
  }
}

{
  "servers": {
    "ocm-fleet": {
      "type": "stdio",
      "command": "ocm-mcp-server",
      "env": {
        "OCM_MCP_HUB_CONTEXT": "kind-hub",
        "OCM_MCP_SPOKE_CONTEXTS": "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"
      }
    }
  }
}

[mcp_servers.ocm-fleet]
command = "ocm-mcp-server"

[mcp_servers.ocm-fleet.env]
OCM_MCP_HUB_CONTEXT = "kind-hub"
OCM_MCP_SPOKE_CONTEXTS = "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"

{
  "mcpServers": {
    "ocm-fleet": {
      "command": "ocm-mcp-server",
      "env": {
        "OCM_MCP_HUB_CONTEXT": "kind-hub",
        "OCM_MCP_SPOKE_CONTEXTS": "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"
      }
    }
  }
}

{
  "mcpServers": {
    "ocm-fleet": {
      "command": "ocm-mcp-server",
      "env": {
        "OCM_MCP_HUB_CONTEXT": "kind-hub",
        "OCM_MCP_SPOKE_CONTEXTS": "cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3"
      }
    }
  }
}

examples/system-prompt.md の手順書に沿った運用をエージェントに指示してから、 何かを壊して、その後の流れを確認してみましょう。

make inject SCENARIO=failing-rollout CLUSTER=cluster2

あなた：「フリート内のどこかで Payments の状態が悪化しています。調査して修正してください。」

エージェント： list_clusters → get_cluster_health(cluster2) → query_events → get_pod_logs → 「cluster2 の payments-v2 が ImagePullBackOff になっています。最後に正常だったイメージを固定する ManifestWork を提案します。提案 4f1a2b3c の承認が必要です。」

あなた（信頼できるターミナル）： ocm-mcp approve 4f1a2b3c を実行し、トークンを貼り付けます。

エージェント： apply_manifestwork → 復旧を確認 → get_audit_trail → インシデントレポートを作成します。

次に、危険な操作をさせようとしてみてください（「privileged と hostNetwork を有効にして再デプロイして。そっちのほうが速いから」など）。 提案はレイヤー 1 またはレイヤー 2 で拒否され、拒否メッセージでその理由がエージェントに正確に伝わります。実例を見る →

アーキテクチャ

_{危険な機能は存在しません。読み取りは自由に行えます。変更はすべて提案され、ポリシーでチェックされ、人間が承認し、監査されます。}

flowchart LR
    A["🤖 AI Agent<br/>(any MCP client)"] -->|"typed tool calls"| S["🛡️ ocm-mcp-server<br/>static guardrails · audit"]
    S -->|"reads + dry-run + apply"| H["☸️ OCM Hub<br/>Placement · ManifestWork<br/>Kyverno · RBAC"]
    H --> C1["cluster1"]
    H --> C2["cluster2"]
    H --> C3["cluster3"]
    U["🧑‍💻 Human operator<br/>ocm-mcp approve"] -.->|"approval token"| A
    S -.->|"spans"| J["🔍 OpenTelemetry / Jaeger"]

書き込みの流れを一文で説明すると、エージェントが ManifestWork を提案し、静的ガードレールと Kyverno のドライランで検証した後、人間が正確な内容を確認して、そのハッシュに紐づいた承認トークンを発行し、その後に限って apply が変更を適用します。各ステップは追跡され、ログに記録されます。

Kyverno によるポリシー admission

2 つ目のガードレール層はこのサーバー内ではなく、クラスター内にあります。提案された変更が保存される前に、サーバーはハブ上で ManifestWork のサーバーサイドのドライラン作成を行います。これにより、ハブの Kyverno の検証 admission が、エージェントが適用しようとしているマニフェストそのものに対して実行されます。組織のポリシーで許可されていなければ、ポリシー自身のメッセージとともに admission で提案が拒否されます。これは、すべての人間による kubectl apply を制御するものと同じ仕組みです。

Kyverno を選ぶ理由：

• 新しい言語を必要としないポリシー・アズ・コード。 Kyverno は CNCF のポリシーエンジンです。ポリシーは通常の Kubernetes リソースとして YAML と CEL で記述するため、あらゆるマニフェストと同様にレビュー、バージョン管理、テストが可能です。これは CNCF Kubernetes Policy Management ホワイトペーパー（CNCF TAG Security）が推奨するポリシー・アズ・コードのアプローチです。ポリシーは宣言的に保ち、アプリケーションコードとは分離します。
• プロンプトではなく、クラスターによって強制されます。 admission control はモデルとこのサーバーの外部にあり、システムプロンプトのように説得して回避することはできません。
• 用途に適したツールです。 Kyverno は検証、変更、生成、イメージの検証ができます。ここでは、ManifestWork に埋め込まれたワークロードを検証するために使われています。

ここでの使用箇所：

• deploy/policies/ には、ManifestWork 内の spec.workload.manifests を foreach で処理する ClusterPolicy オブジェクトが 9 つ含まれています。特権アクセスやホストアクセスの禁止、システム名前空間の保護、kind の許可リストの強制、サーバーの ServiceAccount 由来の managed-by ラベルの必須化（ラベルのない work がほかのポリシーを回避できないようにするため）、および静的ガードレールと同等の Restricted-Pod-Security ベースラインの強制を行います。これらは app.kubernetes.io/managed-by: ocm-mcp-server ラベルでスコープされ、エージェントが作成した work のみを判定します。単独でも使用できます。 deploy/policies/README.md では、マニフェストを埋め込んだ状態で foreach 処理するパターン、導入者が変更する 2 つの識別子、およびこのポリシーパックで実際にテストした Kyverno のバージョンについて説明しています。
• make policy-test は kyverno CLI を使用して、46 ケースのオフラインテストスイートを実行します。正常、不正、人間が作成した ManifestWorks を対象とし、クラスターも依存関係も必要ありません。CI で実行されるため、ポリシーのリグレッションがあれば、ハブに到達する前にビルドが失敗します。
• ゼロから始める必要はありません。コミュニティライブラリの kyverno/policies と、検索可能な Kyverno Policies カタログは、検証、Pod Security Standards、ベストプラクティスポリシーを採用したり、参考にしたりするための情報源です。

ツールセット

公開されているのは、10 個のツールセットにわたる 37 個のツールです。ほぼすべてが読み取り専用です。Open Cluster Management API 全体を安全に調査できます。何かを変更できるツールセットは 2 つだけで、いずれも提案 -> 承認 -> 適用のゲートを通す場合に限られます。ハブレベルのすべてのツールは、スタンドアロンの OpenShift クラスター、HyperShift のホステッドクラスター、クラウドクラスターのいずれにも対応します。ハブ上では、いずれも ManagedCluster だからです。

_{全体像です。8 つのツールセットは一切変更できません。変更できる 2 つのツールセットには、ロックが付いています。}

すべての読み取りツールには readOnlyHint が付与され、すべての書き込みツールには destructiveHint が付与されており、ゲートによって強制されています。OCM_MCP_READ_ONLY=1 を設定すると、書き込み可能な 2 つのツールセットが完全に無効になり、厳密に調査専用のデプロイになります。

1 つのコマンドで自分のハブを検証できます： ocm-mcp doctor はライブハブに対してすべての読み取りツールを呼び出し、PASS / EMPTY / SKIP / FAIL の表を出力します（何も書き込みません）。これにより、エージェントを接続する前に、サーバーが何を認識しているかを正確に確認できます。

_{2 つの経路を規模に応じて示しています。読み取りはすぐに応答しますが、書き込みは提案、人間による署名、1 回限りのトークンによる適用を経由します。}

Secrets を読み取るツール、Pod 内で exec するツール、任意のリソースを削除するツールは、意図的に用意していません。汎用リーダー（list_resources / get_resource）は OCM タイプの許可リストを対象とするため、Secrets は制限されているのではなく、単に指定できません。存在しない機能を、プロンプトインジェクションで使わせることはできません。

ツール

各ツールには、クラスが注記されています。read（無料、ゲートなし）、propose（保留中の変更を保存し、何も変更しない）、apply（承認済みの変更を適用し、人間のトークンが必要）です。

プロンプト

サーバーには、10 個の MCP プロンプトも含まれています。安全なワークフローを定義した再利用可能なテンプレートにより、どのクライアントでも白紙の状態からではなく、適切なランブックを使って開始できます。

リソース

サーバーは 6 個の MCP リソースも公開します。クライアントがツール呼び出しなしで固定、閲覧、またはコンテキストとして添付できる、読み取り専用のフリート状態です（読み取りツールの厳密なサブセットです。アクセスごとに監査ログが記録されます）。

可観測性 - 監査、トレース（OpenTelemetry/Jaeger）、メトリクス

各ツール呼び出しでは、用途の異なる最大3つの独立した記録が生成されます。

_{同じ呼び出しを2通りで記録します。前の行を編集するとチェーンがそれを示します。一方、スパンが示すのは時間がかかった箇所だけです。}

トレースとは： OpenTelemetry は分散トレーシングの CNCF 標準です。Jaeger は CNCF のトレースビューアーです。有効にすると、このサーバーはツール呼び出しごとに1つのスパンを作成します。スパン名は tool.<name>（例：tool.apply_manifestwork）で、呼び出しの引数が属性として付加されます。approval_token が付加されることは決してありません。また、引数の値は200文字で切り詰められるため、トレースを共有バックエンドに送信しても安全です。

監査ログと併用する理由： 監査ログは追記専用で改ざんを検知できる安全性のための成果物です。一方、スパンはデバッグのための成果物です。Jaeger では、たとえば get_cluster_health の呼び出しが1つのスポークでの待機に4秒かかったことを確認したり、インシデントにおける propose → apply の一連の流れをタイムラインで追ったりできます。安全性に関わる処理がスパンを信頼することはありません。そのため、トレーシングはオプションのままで、障害時も安全に動作します。追加の依存関係がインストールされておらず、エンドポイントも設定されていない場合は何もしません。

使用方法（2つのスイッチとビューアー）：

pip install "ocm-mcp-server[tracing]"                    # OTel SDK + OTLP/HTTP exporter
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 # your collector

# a local Jaeger to look at traces (make bootstrap starts this for you):
podman run -d --name jaeger -p 16686:16686 -p 4318:4318 jaegertracing/all-in-one:1.60
# open http://localhost:16686 and select the "ocm-mcp-server" service

テスト方法： ユニットテストでは、スパンの作成、トークンの秘匿、何もしない場合の経路を検証します。E2E スイートにはトレースのエクスポート手順が含まれており、ローカル OTLP シンクを起動し、新しいサーバープロセスでツールを呼び出して、tool.* スパンと ocm-mcp-server サービスの両方を示す実際のトレースバッチが届くことを確認します。これにより、make e2e の実行時と夜間の CI 実行時に、エクスポートの接続が毎回検証されます。詳細：デプロイガイド - トレーシングおよびアーキテクチャ - 可観測性。

クイックスタート（ノートパソコン、約15分）

_{3つの導入方法があります。どの方法でも役立つ結果が得られるため、最初の方法で答えが得られれば、3つ目まで進む必要はありません。}

必要条件：podman（または docker）、kind、kubectl、 clusteradm、helm、Python 3.11 以降、 Linux または macOS（Windows はサポート対象外です。WSL2 を使用してください）。 インストールコマンドと実際のフリートでの手順については、デプロイガイドを参照してください。

git clone https://github.com/ocm-mcp-server/ocm-mcp-server.git
cd ocm-mcp-server

make bootstrap      # 1 hub + 3 managed kind clusters, OCM, Kyverno, policies, demo app
make install        # pip install -e ".[dev,tracing]"

設定

サーバーの設定はすべて環境変数で行います。特に重要なのは、kubeconfig のコンテキスト名の2つです。 コンテキスト名について初めて知る方は、コンテキスト名ガイドで、ノートパソコン上の kind クラスターからクラウドへのログインまで、コンテキスト名の説明と確認に使う正確なコマンドを紹介しています。要約すると、kubectl config get-contexts を実行して NAME 列を確認してください（make bootstrap の最後に、そのまま貼り付けて使える値が表示されます）。

# the values make bootstrap prints, spelled out:
export OCM_MCP_HUB_CONTEXT=kind-hub                      # context of the hub cluster
export OCM_MCP_SPOKE_CONTEXTS=cluster1=kind-cluster1,cluster2=kind-cluster2,cluster3=kind-cluster3
#                             └ name on the hub ┘ └ kubeconfig context with read-only creds ┘

kind-hub や cluster1=kind-cluster1 の出どころ、あるいはご自身の環境で使う値がわからない場合は、 コンテキスト名ガイドで、クラウドへのログイン（EKS、GKE、AKS、OpenShift）も含め、 手順を追って確認できます。kind ではなく実際のフリートを指定する場合も、同じ変数を使います。 読み取り専用のスポークアカウントと本番環境のセキュリティ強化については、 デプロイガイドをご覧ください。

その後、サーバーをエージェントに渡します。すぐに使えるクライアント設定は、この README の上部にある エージェントを接続するに記載されています。

評価ハーネス：ありのままの数値

eval/ には、3 つのクラスに分類された 22 件のインシデントシナリオが用意されています。修復（15 件）、診断のみ（3 件）、敵対的（4 件）です。3 つすべての評価軸を客観的に採点します。トランスクリプト内の診断キーワード、復旧における実際のクラスター状態、安全性に関するサーバー独自の監査ログです。

python3 eval/run_eval.py --agent-cmd "claude -p"     # or any agent CLI

公開済みの結果（eval/results/published/）。失敗も含みます。各行から個別の生 JSON にリンクしています。

すべての実行で、同じビルド（v0.6.0、37 ツール、MCP SDK 2.1.1）、同じフリート、同じ 22 件のシナリオを使用しました。所要時間は実行全体の経過時間です。agy の実行では推論レベルを固定していません。この CLI ではモデルの設定が high／medium／low のみで、実行時にはデフォルトが使われたため、正確なレベルは記録されていません。

未測定は、エージェントがツールを呼び出さなかったシナリオの数です。そのため、サーバーには一度も問い合わせが行われていません。リクエストがガードレールに届く前に、エージェントが独自に拒否しました。これらを安全性の分母から除外しているのは、どちらに数えても誤った報告になるためです。実際には達成していないガードレールの成功として数えるか、発生していない失敗として数えることになります。

安全性はこのサーバーが存在する理由であり、サーバーに到達したすべてのシナリオで安全性は保たれました。注目すべきなのは、その隣にある数値です。最先端のモデルは敵対的な誘導に対し、ツールを呼び出す前に拒否することが増えています。その結果、ガードレールには一度も問い合わせが行われず、提示されなかった誘導がブロックされた誘導と同じスコアになってしまいます。復旧の失敗は、修正に必要な状態が読み取り用インターフェースから意図的に隠されているシナリオに集中しています。

_{診断と復旧はエージェントに属する評価軸であり、飾らずに公開しています。安全性はこのサーバーが責任を負う評価軸であり、全件を公開しています。}

任意のモデルで実行し、失敗も含めて数値を公開してください。エージェントに何ができ、何を任せるにはまだ早いのか、実際のデータを示すことが目的です。

Kyverno ポリシーには独自のオフラインテストスイートがあります。make policy-test を実行すると、クラスターも依存関係も使わずに、適切な ManifestWorks、不適切な ManifestWorks、人間が作成した ManifestWorks を対象とする 46 件の CLI ケース（deploy/policies/tests/）が実行されます。CI でも実行されるため、ポリシーに退行があると、ハブに到達する前にビルドが失敗します。

エンドツーエンドで試す（1 つのコマンド）

モックではなく、実際のクラスターで動作することを確かめたいですか？ 1 つのスクリプトで kind 上に実際の Open Cluster Management フリートを立ち上げ、すべてのツールとプロンプトを実行し、問題発生から修正までのシナリオを実施して、グラフィカルな HTML レポートを作成します。

./hack/e2e-local.sh          # 2 spokes, auto-cleanup   (SPOKES=1 for a lighter run)

このスクリプトは、（1）依存関係（Podman、kind、kubectl、clusteradm、helm。Docker は不要）をインストールするか、バージョンを確認し、（2）ハブとスポークを起動し、（3）すべての読み取りツール、ゲートで制御された提案 → 承認 → 適用の書き込みフロー、ゲートで制御された ROLLBACK フロー、すべてのライフサイクル操作（cordon/uncordon、set_label、accept、enable/disable_addon）、および 10 個すべてのプロンプトを実行します。各操作の内容と目的を平易な言葉で説明します。（4）公式 MCP クライアントを使い、stdio JSON-RPC 経由で実際のサーバーバイナリを実行します（ハンドシェイク、ツール、プロンプト、リソース、アノテーション）。（5）すべてのゲートがフェイルクローズすることを確認する否定テスト一式（期限切れのトークン、再利用されたトークン、ロールバックに適用範囲が限定されたトークンの拒否、読み取り専用モード、改ざんされた監査ログの検出、署名付き監査アンカーの検証）に加え、トレースのエクスポート確認（OTLP 経由の OTel スパンをローカルのシンクで受信）を実行します。（6）ロールアウトの失敗を注入し、診断から修正までのループをエンドツーエンドで実演します。その後、（7）e2e-report.html を作成してフリートを完全に削除します（kind と Podman はインストールされたままです）。レポートは Git の追跡対象外です。macOS（Homebrew + Podman）と Linux で動作し、CI で毎晩実行されます。

ocm-mcp doctor は、任意のハブに対して、ライブ読み取りパスのスモークテストのみを単独で実行します。

実際の、未編集の実行例はこちらです（asciinema で記録。長い待ち時間は短縮されています）。フリートが起動し、すべての手順が成功した後、フリートが削除されます。 MP4 版 · ターミナル録画：

リポジトリの構成

src/ocm_mcp_server/   the MCP server: tools, guardrails, approvals, tracing, CLI
deploy/               least-privilege RBAC + Kyverno ClusterPolicies (+ offline tests)
hack/                 bootstrap.sh / teardown.sh / demo app (kind-based fleet)
chaos/                failure-injection scenarios (reversible, diagnosable)
eval/                 22-scenario evaluation harness + results
blogs/                long-form posts (canonical drafts; published to Medium)
docs/                 deployment, examples, architecture, guardrails, demo, upstream
examples/             MCP client configs (Claude, VS Code, Codex, Gemini) + system prompt

ロードマップ

テーマ別ロードマップの正式版は ROADMAP.md にあります。現在の主な項目： ツールごとのスコープを設定できる認証済み HTTP トランスポート、ホスト外（KMS/HSM）の承認署名者、 OCM クラスタープロキシトランスポート、再利用可能な Kyverno ポリシーパックです。 （マルチモデル評価の結果は現在公開されています。）

お探しの項目がありませんか？機能リクエストを投稿してください。 新しいツールには安全性に関する根拠が必要です。CONTRIBUTING.md をご覧ください。

貢献とコミュニティ

Issue と PR を歓迎します。CONTRIBUTING.md から始めてください。 サポートが必要な場合：SUPPORT.md。 セキュリティに関する報告（非公開でお願いします）：SECURITY.md。

スポンサーシップ

このプロジェクトは独立してメンテナンスされています。優先的なインテグレーション支援、 強化されたデプロイのレビュー、スポンサー付き機能、安全なエージェント型運用に関する講演や ワークショップをご希望の組織は、 LinkedIn からご連絡ください（詳細は SUPPORT.md をご覧ください）。

作者

Sandeep Bazar - テクノロジー、特にマルチクラスタ Kubernetes プラットフォーム、Day 2 運用、フリートの自動化をより安全にすることに情熱を注いでいます。

このプロジェクトが役に立ったら、⭐ を付けていただくと、ほかの人にも見つけてもらいやすくなります。

プロジェクトのガバナンスと成熟度

このプロジェクトでは、CNCF コミュニティ、ガバナンス、セキュリティの実践を品質基準として採用しています。CNCF Sandbox プロジェクトに求められるものと同じ基準を満たすことで、導入や貢献がしやすく、信頼できるプロジェクトを目指しています。基盤は整っています。

• ガバナンス - 意思決定の方法と、メンテナーになる方法を説明しています。
• メンテナー と 導入事例 - メンテナーの一覧と、利用者を記録する公開ページです。
• ロードマップ - 安全性を最優先した、テーマ別の今後の方向性です。
• セキュリティ自己評価 - 保証の内容とその範囲を評価する、CNCF TAG-Security 形式の評価です。
• CNCF Sandbox の準備状況 - 品質基準として用いる、CNCF Sandbox の期待事項に照らした自己評価です。
• 行動規範 - CNCF コミュニティ行動規範です。LinkedIn から非公開で報告できます。

貢献は DCO に基づいて承認されます。これはチェックリストで求めるだけでなく、すべてのプルリクエストで CI ジョブによって適用されます。公開済みのリリースタグは変更できず、ガードレールに関わる変更には、書面による安全性の根拠が必要です。

ライセンス

Apache-2.0