SelfSigned

⚠️ 自己署名発行者は、一般的にローカルでのPKIブートストラップに役立ちますが、これは上級ユーザー向けの複雑なトピックです。本番環境で安全に使用するには、PKIを実行することで、ローテーション、トラストストアの配布、ディザスタリカバリに関する複雑な計画要件が発生します。

独自のPKIを実行する予定がない場合は、別の発行者タイプを使用してください。

自己署名発行者は、それ自体が認証局を表すものではありません。代わりに、証明書が指定された秘密鍵を使用して「自己署名」されることを示します。言い換えれば、証明書の秘密鍵を使用して証明書自体に署名します。

この発行者タイプは、カスタムPKI（公開鍵インフラストラクチャ）のルート証明書のブートストラップ、または簡単なテストのためのアドホック証明書の生成に役立ちます。

自己署名発行者には、セキュリティ上の問題を含む重要な注意点があります。一般的には、自己署名発行者ではなくCA発行者を使用することをお勧めします。ただし、自己署名発行者は、最初にCA発行者をブートストラップする際に非常に役立ちます。

注：自己署名証明書を参照するCertificateRequestには、cert-manager.io/private-key-secret-nameアノテーションも含まれている必要があります。これは、CertificateRequestに対応する秘密鍵が証明書の署名に必要であるためです。このアノテーションはCertificateコントローラーによって自動的に追加されます。

デプロイメント

自己署名発行者は他のリソースに依存しないため、構成が最も簡単です。発行者仕様にはSelfSignedスタンザのみが存在する必要があり、他の構成は必要ありません。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
  namespace: sandbox
spec:
  selfSigned: {}

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-cluster-issuer
spec:
  selfSigned: {}

デプロイメント後、発行者が署名準備完了であることをすぐに確認できます。

$ kubectl get issuers  -n sandbox -o wide selfsigned-issuer
NAME                READY   STATUS                AGE
selfsigned-issuer   True                          2m

$ kubectl get clusterissuers -o wide selfsigned-cluster-issuer
NAME                        READY   STATUS   AGE
selfsigned-cluster-issuer   True             3m

CA発行者のブートストラップ

自己署名発行者の理想的なユースケースの1つは、cert-manager CA発行者を含め、プライベートPKIのカスタムルート証明書をブートストラップすることです。

以下のYAMLは、自己署名発行者を作成し、ルート証明書を発行し、そのルートをCA発行者として使用します。

apiVersion: v1
kind: Namespace
metadata:
  name: sandbox
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-selfsigned-ca
  namespace: sandbox
spec:
  isCA: true
  commonName: my-selfsigned-ca
  secretName: root-secret
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
    group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-ca-issuer
  namespace: sandbox
spec:
  ca:
    secretName: root-secret

あるいは、自己署名Certificate CAを使用してクラスタ内のどこでもCertificatesに署名するためにClusterIssuerを使用する場合は、以下のYAMLを使用してください（最後のステップがわずかに変更されています）。

apiVersion: v1
kind: Namespace
metadata:
  name: sandbox
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-issuer
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-selfsigned-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: my-selfsigned-ca
  secretName: root-secret
  privateKey:
    algorithm: ECDSA
    size: 256
  issuerRef:
    name: selfsigned-issuer
    kind: ClusterIssuer
    group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: my-ca-issuer
spec:
  ca:
    secretName: root-secret

"selfsigned-issuer" ClusterIssuerはルートCA証明書の発行に使用されます。次に、"my-ca-issuer" ClusterIssuerは、証明書の発行と、新しく作成されたルートCA Certificateを使用した署名に使用されます。これは、将来のクラスタ全体の証明書に使用します。

CRL配布ポイント

オプションで、CRL配布ポイントを文字列の配列として指定できます。各文字列は、発行された証明書の失効状況を確認できるCRLの場所を識別します。

...
spec:
  selfSigned:
    crlDistributionPoints:
    - "http://example.com"

注意点

信頼

自己署名証明書を使用するクライアントは、事前に証明書を所有していない限り、それらを信頼する方法がありません。クライアントがサーバーとは異なる名前空間にある場合、これは管理が困難になる可能性があります。

この制限は、trust-managerを使用してca.crtを他の名前空間に配布することで対処できます。

トラストストアの配布の問題を解決するための安全な代替手段はありません。「TOFU」（Trust-on-First-Use）を使用して証明書を信頼することはできますが、その方法は中間者攻撃に対して脆弱です。

証明書の有効性

自己署名証明書の副作用の1つは、そのサブジェクトDNとその発行者DNが同一であることです。X.509 RFC 5280、セクション4.1.2.4では、以下が要求されます。

issuerフィールドには、空ではない識別名（DN）を含める必要があります。

しかし、自己署名証明書には、デフォルトでサブジェクトDNが設定されていません。証明書のサブジェクトDNを手動で設定しない限り、発行者DNは空になり、証明書は技術的には無効になります。

この仕様の特定の領域の検証は断片的であり、TLSライブラリによって異なりますが、将来的にライブラリがその検証を（完全に仕様の範囲内で）改善し、空の発行者DNを持つ証明書を使用している場合にアプリケーションが壊れるリスクが常に存在します。

これを回避するには、自己署名証明書のサブジェクトを設定してください。これは、自己署名発行者によって発行されるcert-manager Certificateオブジェクトでspec.subjectを設定することで実行できます。

バージョン1.3以降、cert-managerは、空の発行者DNを持つ自己署名発行者によって証明書が作成されていることを検出した場合、BadConfigタイプのKubernetes 警告イベントを発行します。