導入Cert-Manager [1]は、Kubernetesクラスター内のTLS証明書の管理を自動化するためのオープンソースツールです。 Kubernetes カスタム リソース定義 (CRD) メカニズムを使用して、証明書の作成、更新、削除を簡単にします。 デザインコンセプトCert-Manager は、Kubernetes API を使用して管理できる Pod、Service、Deployment と同様に、TLS 証明書をリソースとして扱います。カスタム リソース定義 (CRD) メカニズムを使用して、Kubernetes API を拡張することで証明書のライフサイクルを管理するための標準化された方法を提供します。 建築デザインCert-Manager のアーキテクチャは、制御層とデータ層の 2 つの層に分かれています。 制御層: 証明書の作成、更新、削除など、証明書の管理を担当します。 データ層: 証明書の秘密キー、証明書要求、証明機関などの証明書関連データを保存します。 Cert-Manager は、**自己署名証明書**、Let's Encrypt、HashiCorp Vault、Venafi など、複数の証明機関をサポートしています。また、HTTP 認証、DNS 認証、TLS-SNI 認証など、複数の認証方法もサポートしています。これらの検証方法は、証明書の発行機関が信頼できるものであり、証明書の秘密鍵が漏洩していないことを確認するのに役立ちます。 使用シナリオCert-Manager には、次のような幅広い使用シナリオがあります。 - HTTPS アクセス: Cert-Manager を使用すると、Kubernetes クラスター内のサービスと Ingress の TLS 証明書を簡単に作成し、HTTPS アクセスを有効にすることができます。
- デプロイメントのセキュリティ: Cert-Manager は、Kubernetes クラスター内の Pod に対して TLS 証明書を作成し、Pod 間の通信が暗号化されることを保証できます。
- サービス間認証: Cert-Manager は、Kubernetes クラスター内のサービスに対して TLS 証明書を作成し、サービス間の通信が暗号化されることを保証できます。
- その他のアプリケーション シナリオ: Cert-Manager は、通信が暗号化されていることを確認するために、他のアプリケーションの TLS 証明書を作成するためにも使用できます。
実用的な問題を解決- 自動証明書管理: Cert-Manager は、手動介入なしで TLS 証明書を自動的に管理し、証明書を自動的に発行し、有効期限前に証明書を更新することで、証明書管理の複雑さとエラーを回避します。
- セキュリティ: Cert-Manager は、証明書の発行機関が信頼できるものであり、証明書の秘密鍵が漏洩していないことを保証し、通信のセキュリティを向上させるのに役立ちます。
- 管理コスト: Cert-Manager は、証明書の管理方法を標準化することで、証明書管理のコストとプロセスを簡素化できます。
cert-managerを使用して証明書を作成するプロセスKubernetes では、cert-manager は次のプロセスを通じて証明書を発行するためのリソース オブジェクトを作成します。 - 証明書名、ドメイン名などの証明書関連の情報が含まれる CertificateRequest オブジェクトを作成します。このオブジェクトは、使用する Issuer または ClusterIssuer と、証明書の発行後に保存される Secret の名前を指定します。
- Issuer または ClusterIssuer は、証明書要求の関連情報に基づいて Order オブジェクトを作成し、証明書を発行する必要があることを示します。このオブジェクトには、証明書を発行するために必要なドメイン名リストや証明書発行機関の名前などの情報が含まれています。
- 証明書発行機関は、Order オブジェクトの情報に基づいて 1 つ以上の Challenge オブジェクトを作成し、証明書申請者のドメイン名に対する制御を確認します。チャレンジ オブジェクトには、ドメイン名の所有権を証明する DNS レコードまたは HTTP サービスが含まれています。
- cert-manager は、Challenge オブジェクトの ChallengeResponse 応答を受信すると、それを解決済みの状態に更新します。証明書発行機関はすべてのチャレンジ オブジェクトをチェックし、すべてが検証に合格した場合に証明書を発行します。
- 証明書が発行されると、証明書発行機関は証明書情報を Secret オブジェクトに書き込み、Order オブジェクトを完了としてマークします。証明書情報は、他の展開オブジェクトでも使用できるようになりました。
cert-manager が k8s で証明書を作成するプロセス全体は、次のフローチャートで説明できます。 +-------------+
| |
|イングレス/ |
|注釈|
| |
+------+------+
|
|イングレスの変更を監視する
|
ヴ
+-------------+
| |
|発行者/ |
|クラスター発行者|
| |
+------+------+
|
|証明書リクエストの作成
|
ヴ
+------+------+
| |
|証明書リクエスト|
| |
+------+------+
|
|注文を作成
|
ヴ
+------+------+
| |
|注文|
| |
+------+------+
|
|チャレンジを作成する
|
ヴ
+------+------+
| |
|チャレンジ|
| |
+------+------+
|
|挑戦に応える
|
ヴ
+------+------+
| |
|チャレンジレスポンス|
| |
+------+------+
|
|証明書を発行する
|
ヴ
+------+------+
| |
|秘密|
| |
+------+------+ 実際に手動で練習すると、次のコマンドで各プロセスの情報を表示できます。 kubectl は証明書リクエスト、注文、チャレンジを取得します この時点で、設計コンセプト、アーキテクチャ設計、使用シナリオ、および cert-manager によって解決される実際の問題を理解した後、cert-manager を使用して実際のプロジェクトの証明書を作成できます。 インストールと設定cert-manager をインストールします。 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.yaml
名前準備完了ステータス再起動年齢
cert - manager - 5 d495db6fc - 6 rtxx 1 / 1実行中0 9 m56s
cert - manager - cainjector - 5f 9 c9d977f - bxchd 1 / 1実行中0 9 m56s
cert - manager - webhook - 57 bd45f9c - 89 q87 1 / 1実行中0 9分56秒 cmctl コマンドライン ツールを使用して、cert-manager が正常かどうかを確認します。 醸造インストールcmctl
cmctlチェックAPI インストールが完了すると、Cert-manager は CRD (カスタム リソース定義) と、証明書やキーなどの関連リソースを自動的に作成します。 cert-manager webhook が正常かどうかを確認します。 cat << EOF > 02 -テスト-リソース.yaml
APIバージョン: v1
種類:名前空間
メタデータ:
名前:証明書-マネージャー-テスト
---
apiバージョン: cert-manager.io/v1
種類:発行者
メタデータ:
名前:テスト-自己署名
名前空間: cert - manager - test
仕様:
自己署名: {}
---
apiバージョン: cert-manager.io/v1
種類:証明書
メタデータ:
名前:自己署名証明書
名前空間: cert - manager - test
仕様:
dns名:
-例。 com
secretName :自己署名-証明書- TLS
発行者参照:
名前:テスト-自己署名
終了
kubectl適用- f 02 -テスト-リソース.yaml
kubectl削除- f 02 -テスト-リソース.yaml cert-manager の証明書発行エンティティ オブジェクトを作成するcert-manager の Issuer と ClusterIssuer はどちらも、証明書の発行先のエンティティを定義するために使用されるリソース オブジェクトです。 - 発行者は、名前空間内で証明書を発行するために使用される名前空間レベルのリソースです。たとえば、自己署名証明書を使用してサービスを保護する必要がある場合や、Let's Encrypt などのパブリック証明機関を使用して証明書を発行する必要がある場合に、Issuer を使用できます。
- ClusterIssuer は、クラスター全体に証明書を発行するために使用されるクラスター レベルのリソースです。たとえば、会社の内部 CA を使用して証明書を発行する必要がある場合は、ClusterIssuer を使用できます。
両者の違いを理解した上で、使用状況に応じて発行者のタイプを決定できます。よく使用される発行者テンプレートをいくつか示します。 apiバージョン: cert-manager.io/v1
種類:発行者
メタデータ:
名前: letsencrypt -ステージング
仕様:
アクメ：
# ACMEサーバーのURL
サーバー: https://acme-staging-v02.api.letsencrypt.org/directory
# ACME登録に使用するメールアドレス
メール: [email protected] #ここにメールアドレスを入力してください
# ACMEアカウントの秘密鍵を保存するために使用するシークレットの名前
秘密鍵シークレット参照:
名前: letsencrypt -ステージング
# HTTP - 01チャレンジプロバイダーを有効にする
ソルバー:
- http01 :
入口:
クラス: nginx
ステージング環境を使用して発行された証明書は、パブリック ネットワークでは通常使用できないため、信頼されたルート証明書をローカルに追加する必要があります。
apiバージョン: cert-manager.io/v1
種類:発行者
メタデータ:
名前: letsencrypt - prod
仕様:
アクメ：
# ACMEサーバーのURL
サーバー: https://acme-v02.api.letsencrypt.org/directory
# ACME登録に使用するメールアドレスクラウドネイティブエコシステムをフォローする
メールアドレス: [email protected]
# ACMEアカウントの秘密鍵を保存するために使用するシークレットの名前
秘密鍵シークレット参照:
名前: letsencrypt - prod
# HTTP - 01チャレンジプロバイダーを有効にする
ソルバー:
- http01 :
入口:
クラス: nginx - ステージング環境用の証明書発行者 ClusterIssuer を作成します。
apiバージョン: cert-manager.io/v1
種類: ClusterIssuer
メタデータ:
名前: letsencrypt -ステージング
仕様:
アクメ：
# ACMEサーバーのURL
サーバー: https://acme-staging-v02.api.letsencrypt.org/directory
# ACME登録に使用するメールアドレスクラウドネイティブエコシステムをフォローする
メールアドレス: [email protected]
# ACMEアカウントの秘密鍵を保存するために使用するシークレットの名前
秘密鍵シークレット参照:
名前: letsencrypt -ステージング
# HTTP - 01チャレンジプロバイダーを有効にする
ソルバー:
- http01 :
入口:
クラス: nginx - Prod 環境用の証明書発行者 ClusterIssuer を作成します。
apiバージョン: cert-manager.io/v1
種類: ClusterIssuer
メタデータ:
名前: letsencrypt - prod
仕様:
アクメ：
# ACMEサーバーのURL
サーバー: https://acme-v02.api.letsencrypt.org/directory
# ACME登録に使用するメールアドレスクラウドネイティブエコシステムをフォローする
メールアドレス: [email protected]
# ACMEアカウントの秘密鍵を保存するために使用するシークレットの名前
秘密鍵シークレット参照:
名前: letsencrypt - prod
# HTTP - 01チャレンジプロバイダーを有効にする
ソルバー:
- http01 :
入口:
クラス: nginx 実際のアプリケーションでテストするここで、cert-manager を使用して証明書に署名するための準備作業は基本的にすべて完了しました。簡単な例で証明書をテストしてみましょう。ここでは、小さなオープンソースプロジェクトのファイル転送キャビネットを展開します。 APIバージョン: v1
種類:永続ボリューム
メタデータ:
名前: filecodebox - pv
ラベル:
タイプ:ローカル
仕様:
ストレージクラス名:手動
容量：
ストレージ: 5 Gi
アクセスモード:
-ReadWriteOnce
ホストパス:
パス: "/data/filecodebox"
---
APIバージョン: v1
種類: PersistentVolumeClaim
メタデータ:
名前:ファイルコードボックス- pvc
名前空間:ブログ
仕様:
ストレージクラス名:手動
アクセスモード:
-ReadWriteOnce
リソース：
リクエスト:
ストレージ: 5 Gi
---
apiバージョン:アプリ/ v1
種類:デプロイメント
メタデータ:
名前:ファイルコードボックス
名前空間:ブログ
ラベル:
アプリ:ファイルコードボックス
仕様:
レプリカ： 1
テンプレート：
メタデータ:
名前:ファイルコードボックス
ラベル:
アプリ:ファイルコードボックス
仕様:
コンテナ:
-名前:ファイルコードボックス
画像: lanol / filecodebox :最新
imagePullPolicy : IfNotPresent
ボリュームマウント:
-マウントパス: / app / data
名前:ファイルコードボックスデータ
-マウントパス: / etc / localtime
名前:タイムゾーン
読み取り専用: true
再起動ポリシー:常に
巻数:
-名前:ファイルコードボックスデータ
永続ボリュームクレーム:
クレーム名:ファイルコードボックス- pvc
-名前:タイムゾーン
ホストパス:
パス： / usr / share / zoneinfo /アジア/上海
セレクター:
マッチラベル:
アプリ:ファイルコードボックス
---
APIバージョン: v1
種類:サービス
メタデータ:
名前: filecodebox - svc
名前空間:ブログ
仕様:
セレクター:
アプリ:ファイルコードボックス
ポート:
-ポート: 12345
タイプ: ClusterIP
---
apiバージョン:ネットワーク。 k8s 。 io / v1
種類:イングレス
メタデータ:
名前: filecodebox - ingress
名前空間:ブログ
ラベル:
公開元:イングレス
注釈:
cert-manager.io/cluster-issuer : " letsencrypt-prod" #ここでは発行者に基づいてprod証明書を発行します
仕様:
イングレスクラス名: nginx
TLS :
-ホスト:
-ファイル。開発者。中国語
secretName :ファイルコードボックス- tls
ルール:
-ホスト:ファイル.devopsman .cn
http://www.google.com/dp ...
パス:
-パスタイプ:プレフィックス
パス： "/"
バックエンド:
サービス：
名前: filecodebox - svc
ポート:
番号: 12345 作成後、証明書の有効期間を確認して有効かどうかを確認できます。 ルート#エコー | openssl s_client -servername file.devopsman.cn -connect file.devopsman.cn:443 2>/dev/null | openssl x509 -noout -dates
notBefore=2023年3月1日 04:02:01 GMT
notAfter=2023年5月30日 04:02:00 GMT ここで、生成された証明書を kubectl 経由で確認することで確認することもできます。 APIバージョン: cert-manager.io/v1
種類: 証明書
メタデータ:
作成タイムスタンプ: "2023-03-01T05:01:18Z"
世代: 1
ラベル:
公開元: イングレス
名前: filecodebox-tls
名前空間: ブログ
所有者参照:
- APIバージョン: networking.k8s.io/v1
ブロック所有者削除: true
コントローラー: true
種類: イングレス
名前: filecodebox-ingress
uid: 3e2972a3-934b-431f-afee-4f649f5e1df3
リソースバージョン: "26802670"
uid: 3d58d600-87aa-4119-bbdd-6566a8a0331b
仕様:
dns名:
- ファイル.devopsman.cn
発行者参照:
グループ: cert-manager.io
種類: ClusterIssuer
名前:letsencrypt-prod
シークレット名: filecodebox-tls
使用法:
-デジタル署名
- キー暗号化
状態：
条件：
- 最終遷移時間: "2023-03-01T05:02:03Z"
メッセージ: 証明書は最新であり、期限切れではありません
観測世代: 1
理由: 準備完了
ステータス: "True"
タイプ: 準備完了
それ以降: "2023-05-30T04:02:00Z"
以前: "2023-03-01T04:02:01Z"
更新時間: "2023-04-30T04:02:00Z"
改訂: 1 上記の証明書発行から発行までのプロセスを理解した後、次のコマンドでプロセス全体の大まかな詳細を表示できます。 kubectl は証明書リクエスト、注文、チャレンジを取得します この時点で、cert-manager が証明書要求に署名する方法を基本的に理解できました。何か興味深い話題があれば、一緒に話し合うこともできます。次回の記事では、cert-manager を使って社内 LAN 内に自己署名発行者を作成し、コストをできるだけ抑えながら実環境をシミュレートするために必要な証明書を発行する方法について記録する予定です。 | 
