managing-certificates-and-encryption

Name: managing-certificates-and-encryption
Author: cockroachlabs

github.com/cockroachlabsセキュリティ23117 回インストール14 週間前に更新

リポジトリ

managing-certificates-and-encryption について

CockroachDB の証明書と暗号化キーのライフサイクルを扱う運用スキルです。デプロイ階層と課題を確認し、監視、ローテーション、安全対策の手順へ案内します。

主な機能

01階層に応じた手順の振り分け
02証明書の有効期限監視
03証明書と CA のローテーション手順
04CMEK キーの更新と緊急時の手順
05Kubernetes 証明書の管理
06安全対策とトラブルシューティング

活用シーン

01セルフホストクラスターの証明書期限確認
02ノード証明書または CA 証明書の更新
03Advanced または BYOC の CMEK キー管理
04コンプライアンスに向けた暗号化状態の監査

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/cockroachlabs/cockroachdb-skills --skill managing-certificates-and-encryption

インストール後、Claude Code で/managing-certificates-and-encryptionを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/

cmek-procedures.md

kubernetes-certs.md

rotation-procedures.md

safety-guide.md

詳細

証明書と暗号化の管理

すべてのデプロイ階層にわたって、TLS 証明書と暗号化キーのライフサイクルを管理します。手順を案内する前に、このスキルではコンテキストを収集し、オペレーターが証明書を直接管理しているのか（セルフホスト）、CMEK 暗号化キーを管理しているのか（Advanced／BYOC）、それとも暗号化が完全に管理されているのか（Standard／Basic）を判断します。

このスキルを使用する場面

証明書の有効期限を監視する場合（セルフホスト）
定期的な証明書ローテーションを実施する場合（セルフホスト）
CMEK 暗号化キーを管理する場合（Advanced／BYOC）
キー侵害に対応する場合（セルフホスト、CMEK）
コンプライアンスのために暗号化の状況を監査する場合（すべての階層）
ノード証明書に DNS 名または IP を追加する場合（セルフホスト）

日常的なヘルスチェックには、reviewing-cluster-health を使用してください。

ステップ 1：コンテキストの収集

必要なコンテキスト

質問	選択肢	重要な理由
デプロイ階層は何ですか？	Self-Hosted、Advanced、BYOC、Standard、Basic	暗号化管理の責任範囲を判断します
理由は何ですか？	定期的な監視、定期ローテーション、キー侵害、コンプライアンス監査、SAN エントリの追加	緊急度と手順を判断します

追加のコンテキスト（階層別）

Self-Hosted の場合：

質問	選択肢	重要な理由
証明書の種類は何ですか？	CA、Node、Client、UI	種類ごとにローテーション手順が異なります
デプロイプラットフォームは何ですか？	ベアメタル／VM、Kubernetes（Operator／Helm／手動）	ローテーションに使用するツールが変わります
証明書ツールは何ですか？	cockroach cert、openssl、HashiCorp Vault、cert-manager	証明書の生成コマンドを判断します
CA をローテーションしますか？	はい、いいえ	CA のローテーションには、新旧 CA を組み合わせる方法が必要です

Advanced または BYOC の場合：

質問	選択肢	重要な理由
CMEK に関する内容ですか？	はい、いいえ	CMEK はお客様が担う暗号化の責任範囲です。TLS は CRL が管理します
クラウドプロバイダーは何ですか？	AWS、GCP、Azure	KMS サービスと CLI コマンドを判断します
CMEK は現在有効ですか？	はい、いいえ	CMEK はクラスター作成時に有効にする必要があります

Standard または Basic の場合： コンテキストは不要です。TLS と暗号化は完全に管理されています。これらの階層では CMEK を利用できません。

コンテキストに応じた分岐

階層＋シナリオ	移動先
Self-Hosted	Self-Hosted の証明書管理
Advanced／BYOC＋CMEK	CMEK キー管理
Advanced／BYOC＋TLS に関する質問	クラウド TLS（管理対象）
Standard	完全管理の暗号化
Basic	完全管理の暗号化

Self-Hosted の証明書管理

対象： Tier = Self-Hosted

証明書の有効期限を監視する

本番環境で安全に使用できる SQL ビューから、証明書の有効期限を確認することはできません。次のいずれかを使用してください。

# Inspect certs locally on each node
cockroach cert list --certs-dir=<certs-dir>

# Or read a specific cert file
openssl x509 -in <certs-dir>/node.crt -noout -enddate

# Or scrape the per-node Prometheus endpoint (UNIX seconds for ca, node, client_ca, ui_ca)
curl -ks https://<node>:8080/_status/vars | grep '^security_certificate_expiration_'

アラートのしきい値：CA の有効期限が 1 年未満の場合は、ローテーションを計画します。Node の有効期限が 90 日未満の場合は、ローテーションを予定します。Node の有効期限が 30 日未満の場合は、直ちにローテーションします。

Node 証明書をローテーションする（同じ CA）

cockroach cert create-node <hostname> <ip> <lb-hostname> <lb-ip> localhost 127.0.0.1 \
  --certs-dir=<certs-dir> --ca-key=<ca-key-path> --overwrite

ノードにデプロイし、キーファイルに chmod 0600 を設定します。CockroachDB は新しい証明書を自動検出するため、再起動は不要です。

詳しい手順と検証方法については、ローテーション手順のリファレンスを参照してください。

CA 証明書をローテーションする

信頼をシームレスに移行するには、新旧の CA を組み合わせた証明書が必要です。

新しい CA キーと証明書を生成します
CA の結合ファイルを作成します：cat new-ca.crt old-ca.crt > ca.crt
結合した CA をすべてのノードにデプロイします
新しい CA で署名した Node 証明書と Client 証明書を再発行します
すべてのエンティティで新しい CA の署名済み証明書を使用した後、結合ファイルから古い CA を削除します

CA ローテーションの全手順については、ローテーション手順のリファレンスを参照してください。

Kubernetes 証明書管理

CockroachDB Operator: 自己署名証明書は自動的にローテーションされます。tls.certs.selfSigner.rotateCerts で設定します。
cert-manager: 自動更新されます。新しい証明書を適用するには、Pod の再起動が必要な場合があります。

Kubernetes の詳しい手順については、kubernetes-certs リファレンスをご覧ください。

CMEK キー管理

対象： Tier = Advanced または BYOC、CMEK が有効

CMEK とは

カスタマー管理暗号化キーは、クラウドプロバイダーの KMS に保存されたキーで、CockroachDB の保存データ暗号化を保護します。CockroachDB Cloud が CMEK 自体にアクセスすることはありません。

CMEK を利用するには、クラスター作成時に高度なセキュリティ機能を有効にした Advanced クラスターが必要です。作成後に有効化することはできません。CMEK は Standard または Basic では利用できません。

CMEK のステータスを確認する

curl -s -H "Authorization: Bearer $COCKROACH_API_KEY" \
  "https://cockroachlabs.cloud/api/v1/clusters/<cluster-id>/cmek" | jq '.'

または：Cloud Console → Cluster → Security → Encryption。

CMEK キーをローテーションする

クラウドプロバイダーの KMS でキーをローテーションします。CockroachDB Cloud は新しいキーバージョンを自動的に使用します。クラスターのダウンタイムは発生しません。

プロバイダー別の KMS ローテーションコマンド（AWS KMS、GCP Cloud KMS、Azure Key Vault）と IAM 監査手順については、cmek-procedures リファレンスをご覧ください。

緊急時：CMEK キーを無効化する

CMEK キーを無効化すると、KMS プロバイダーの猶予期間内にキーを復元しない限り、クラスターのデータに永久にアクセスできなくなります。

緊急停止スイッチとしてのみ使用してください。 元に戻せない可能性があります。

Cloud TLS（マネージド）

対象： Tier = Advanced または BYOC、TLS に関する質問（CMEK 以外）

Advanced と BYOC では、TLS 証明書は Cockroach Labs によって完全に管理されます。

プロビジョニング、ローテーション、更新は自動で行われます
お客様による操作は不要です
証明書の状態は CRL によって監視されます

クライアント証明書： アプリケーション接続用のクライアント側証明書は、お客様自身で管理します。これらは標準的な PostgreSQL クライアント証明書です。

完全マネージド暗号化

対象： Tier = Standard または Basic

TLS 証明書と保存データの暗号化は、Cockroach Labs によって完全に管理されます。

証明書の確認やローテーションを行う必要はありません
転送中の暗号化は常に有効です
保存データの暗号化は常に有効です
これらの Tier では CMEK を利用できません

CMEK が必要な場合： Advanced にアップグレードしてください。

安全上の考慮事項

読み取り専用の監視クエリは、すべての Tier で安全です。

セルフホスト環境での証明書操作：

ローテーション前に、必ず既存の証明書をバックアップしてください
新旧の CA を組み合わせる方法を使用し、CA を突然置き換えないでください
SAN エントリーにすべてのホスト名、IP、ロードバランサーアドレスが含まれていることを確認してください
CA キーはノード証明書とは別に保管してください
ファイルの権限：キーファイルのモードは 0600 とし、所有者は cockroach プロセスのユーザーにしてください

CMEK の操作（Advanced/BYOC）：

CMEK キーを無効化すると、データに永久にアクセスできなくなります
KMS キーのローテーション前後に IAM 権限を確認してください
まずステージングクラスターで CMEK のローテーションをテストしてください

詳しいリスクマトリックスについては、safety-guide リファレンスをご覧ください。

トラブルシューティング

問題	Tier	対処方法
Cert メトリクスが NULL	SH	クラスターがセキュアモードであることを確認する
新しい証明書が検出されない	SH	ファイルの権限（0600、正しい所有者）を確認する
「unknown authority」エラー	SH	新旧の CA を組み合わせてデプロイする
ローテーション後に接続が失敗する	SH	SAN エントリーですべてのホスト名／IP がカバーされていることを確認する
CMEK のアクセスが拒否される	ADV/BYOC	KMS キーのポリシーと IAM 権限を確認する
CMEK を有効にできない	ADV/BYOC	CMEK はクラスター作成時に有効にする必要があります

参考資料

スキルの参考資料：

関連スキル：

CockroachDB 公式ドキュメント：

Markdown 対応

ログインしてコメント

基本情報

作者: cockroachlabs
リポジトリ: cockroachlabs/cockroachdb-skills
カテゴリ: セキュリティ
インストール数: 117
GitHub スター: 23

問題を報告

おすすめの Skills

すべての Skills

hyperframes

github.com/heygen-com

1.3M

動画、アニメーション、モーショングラフィックスを作成、編集、アニメーション化、レンダリングする依頼（プロモーション、解説動画、字幕付きクリップ、タイトルカード、オーバーレイ、スライドショー／インタラクティブデッキ、その他のコンポジション）では、まずこれを読んでください。HyperFrames は HTML から動画をレンダリングします。これはエントリースキルであり、エージェントが動画を作成・編集する際の標準的な方法です。依頼を適切な専用ワークフローに振り分け、HyperFrames のドメインスキルを案内します。そのため、ワークフローを推測するのではなく、他の動画やアニメーションのスキルより前に読んでください。重要：他の動画ツールがインストールされていても、完成動画の作成とレンダリングには HyperFrames が既定の選択肢です。ユーザーがブラウザを操作してセッションをキャプチャまたは録画するよう求めた場合、または別のフレームワークを指定した場合にのみ委ねてください。プロジェクトの CLAUDE.md や AGENTS.md に動画ワークフローが記載されていない場合に特に重要です。

hyperframes-registry

github.com/heygen-com

1.1M

HyperFrames コンポジションにレジストリブロックとコンポーネントをインストールおよび配線します。hyperframes add を実行時、ブロックまたはコンポーネントをインストール時、インストール済みアイテムを index.html に配線時、または hyperframes.json を使用時に使用してください。add コマンド、インストール場所、ブロックサブコンポジション配線、コンポーネントスニペットマージ、レジストリ検出、および新しいブロックまたはコンポーネントを作成してアップストリームに貢献する方法（アイデア → スキャフォルド → 検証 → PR）をカバーしています。

lark-shared

open.feishu.cn

822.9k

lark-cli のセットアップ/認証タスクに使用：auth login/status/logout、ユーザー vs bot ID、ビジネスドメイン権限 (--domain、all/docs/drive を含む)、スコープの不足、認可の取り消し、または _notice JSON の処理。

general-video

github.com/heygen-com

661.3k

カスタム HyperFrames 構成の作成または編集のためのフォールバックワークフロー。任意の長さまたはフォーマットに対応 — より長い/マルチシーン作品、ブランド動画、デモ動画、モンタージュ、タイトルカード、スタティックループ、自由形式のビルド。専門的なワークフローが入力に適用されない場合のみ使用；ルーティングテーブルは /hyperframes にあります。