新着：プロジェクトの最新情報をTwitterとMastodonで入手しましょう

CA インジェクター

cainjectorは、次のCA証明書の設定を支援します：変更 Webhook、検証 Webhook 変換 Webhook、および API サービス

特に、cainjector は、4つのAPIタイプ（ValidatingWebhookConfiguration、MutatingWebhookConfiguration、CustomResourceDefinition、およびAPIService）のcaBundleフィールドに値を設定します。最初の3つのリソースタイプは、Kubernetes APIサーバーがWebhookにどのように接続するかを設定するために使用されます。このcaBundleデータはKubernetes APIサーバーによってロードされ、Webhook APIサーバーのサーバー証明書を検証するために使用されます。APIServiceは、Extension API Serverを表すために使用されます。APIServiceのcaBundleには、APIサーバーのサーバー証明書の検証に使用できるCA証明書を設定できます。

これらの4つのAPIタイプを注入可能なリソースと呼びます。

注入可能なリソースには、注入のソースに応じて、cert-manager.io/inject-ca-from、cert-manager.io/inject-ca-from-secret、またはcert-manager.io/inject-apiserver-caのいずれかのアノテーションがMUSTでなければなりません。詳細については、以下で説明します。

cainjectorは、3つのソースのいずれか（KubernetesのSecret、cert-managerのCertificate、またはKubernetes APIサーバーのCA証明書（cainjector自体がKubernetes APIサーバーへのTLS接続を検証するために使用するもの）)からCAデータをコピーします。

ソースがKubernetesのSecretである場合、そのリソースにはcert-manager.io/allow-direct-injection: "true"のアノテーションもMUSTでなければなりません。3つのソースタイプについては、以下で詳しく説明します。

例

以下に、3つのcainjectorのソースの使用方法を示す例を示します。各ケースでは、注入可能なリソースとしてValidatingWebhookConfigurationを使用していますが、代わりにMutatingWebhookConfigurationまたはCustomResourceDefinition定義を代用できます。

CertificateリソースからCAデータを注入する

以下は、cert-manager.io/inject-ca-fromアノテーションで構成されたValidatingWebhookConfigurationの例です。これにより、cainjectorは、cert-managerのCertificateからのCAデータを使用してcaBundleフィールドを設定します。

注: この例ではWebhookサーバーはデプロイせず、部分的なWebhook構成のみをデプロイしますが、cainjectorの動作を理解するのに十分なはずです。

apiVersion: v1
kind: Namespace
metadata:
  name: example1


---


apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: webhook1
  annotations:
    cert-manager.io/inject-ca-from: example1/webhook1-certificate
webhooks:
- name: webhook1.example.com
  admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: webhook1
      namespace: example1
      path: /validate
      port: 443
  sideEffects: None


---


apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: webhook1-certificate
  namespace: example1
spec:
  secretName: webhook1-certificate
  dnsNames:
  - webhook1.example1
  issuerRef:
    name: selfsigned


---


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

caBundleの値が、CertificateのSecretのCAの値と同一になっているはずです。

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io webhook1 -o yaml | grep caBundle
kubectl -n example1 get secret webhook1-certificate -o yaml | grep ca.crt

そして、しばらくすると、Kubernetes APIサーバーはその新しいcaBundle値を読み取り、それを使用してWebhookサーバーへのTLS接続を検証します。

SecretリソースからCAデータを注入する

以下は、cert-manager.io/inject-ca-from-secretアノテーションで構成されたValidatingWebhookConfigurationの別の例です。これにより、cainjectorは、KubernetesのSecretからのCAデータを使用してcaBundleフィールドを設定します。

注: この例ではWebhookサーバーはデプロイせず、部分的なWebhook構成のみをデプロイしますが、cainjectorの動作を理解するのに十分なはずです。

apiVersion: v1
kind: Namespace
metadata:
  name: example2


---


apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: webhook2
  annotations:
    cert-manager.io/inject-ca-from-secret: example2/example-ca
webhooks:
- name: webhook2.example.com
  admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: webhook2
      namespace: example2
      path: /validate
      port: 443
  sideEffects: None


---


apiVersion: v1
kind: Secret
metadata:
  name: example-ca
  namespace: example2
  annotations:
    cert-manager.io/allow-direct-injection: "true"
type: kubernetes.io/tls
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM5akNDQWQ2Z0F3SUJBZ0lRTkdJZ24yM3BQYVpNbk9MUjJnVmZHakFOQmdrcWhraUc5dzBCQVFzRkFEQVYKTVJNd0VRWURWUVFERXdwRmVHRnRjR3hsSUVOQk1CNFhEVEl3TURreU5ERTFOREEwTVZvWERUSXdNVEl5TXpFMQpOREEwTVZvd0ZURVRNQkVHQTFVRUF4TUtSWGhoYlhCc1pTQkRRVENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFECmdnRVBBRENDQVFvQ2dnRUJBS2F3RzVoMzlreHdyNEl0WCtHaDNYVWQrdTVJc2ZlSFdoTTc4TTRQTmZFeXhQMXoKRmNLN1d0MHJFMkwwNUppYmQ4ZjNpb3k5OXNnQ3I4OEw2SWxYZTB0RnkzNysxenJ4TFluR2hDQnZzZjltd0hLbgpIVTEvNERwQjROZkhPbFllNE9tbHVoNE9HdmZINU1EbDh5OWZGMjhXRXVBQ2dwdmpCUWxvRDNlVjJ5UmJvQ2kyCmtSTDJWYTFZL0FQZEpWK21VYkFvZmg0bllmUmNLRTJsSUg0RG5ZdXFPU3JaaituZUQ2M2RTSktxcHQ5K2luN2YKNHljZ2pQYU93MmdyKzhLK291QTlSQTV1VDI3SVNJcUJDcEV6elRqbVBUUWNvUTYxZGF0aDZkc1lsTEU4aWZWUwp4RWZuVEdQKy94M0FXQXR4eU5lanVuZGFXbVNFL3h5OHh0K0FxblVDQXdFQUFhTkNNRUF3RGdZRFZSMFBBUUgvCkJBUURBZ0trTUE4R0ExVWRFd0VCL3dRRk1BTUJBZjh3SFFZRFZSME9CQllFRkowNkc5eEc2V1VBTHB6T3JYaHAKV2dsTm5qMkFNQTBHQ1NxR1NJYjNEUUVCQ3dVQUE0SUJBUUI3ZG9CZnBLR3o4VlRQSnc0YXhpdisybzJpMHE1SQpSRzU2UE81WnhKQktZQlRROElHQmFOSm1yeGtmNTJCV0ttUGp4cXlNSGRwWjVBU00zOUJkZVUzRGtEWHp4RkgwCjM5RU12UnhIUERyMGQ4cTFFbndQT0xZY1hzNjJhYjdidE11cTJUMFNNZzRYMkY5VmNKTW5YdjlrNnA0VGZNR3MKVThCQnJhVGhUZm53ejBsWXMyblFjdzNmZjZ1bG1wWlk4K3BTak1aVDNJZHZOMFA4Y2hOdUlmUFRHWDJmSlo2NQpxcUUrelRoU3hIeXFTOTVoczhsd1lRRUhGQlVsalRnMCtQZThXL0hOSXZBOU9TYWw1U3UvdlhydmcxN04xdHVyCk5XcWRyZU5OVm1ubXMvTFJodmthWTBGblRvbFNBRkNXWS9GSDY5ZzRPcThiMHVyK3JVMHZOZFFXCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
  tls.key: ""
  tls.crt: ""

caBundleの値が、Secretのca.crtの値と同一になっているはずです。

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io webhook2  -o yaml | grep caBundle

そして、しばらくすると、Kubernetes APIサーバーはその新しいcaBundle値を読み取り、それを使用してWebhookサーバーへのTLS接続を検証します。

このSecretベースの注入メカニズムは、前述のCertificateベースのメカニズムとは独立して動作できます。cert-manager CRDがインストールされていなくても、またcert-manager CRDと関連付けられたWebhookサーバーがまだ構成されていなくても動作します。

注: このため、cert-managerは、独自のWebhookサーバーをブートストラップするためにSecretベースの注入メカニズムを使用します。cert-managerのWebhookサーバーは、独自の秘密鍵と自己署名証明書を生成し、起動時にSecretに配置します。

Kubernetes APIサーバーCAを注入する

以下は、cert-manager.io/inject-apiserver-ca: "true"アノテーションで構成されたValidatingWebhookConfigurationの別の例です。これにより、cainjectorは、Kubernetes APIサーバーで使用されているのと同じCA証明書を使用して、caBundleフィールドを設定します。

注: この例ではWebhookサーバーはデプロイせず、部分的なWebhook構成のみをデプロイしますが、cainjectorの動作を理解するのに十分なはずです。

apiVersion: v1
kind: Namespace
metadata:
  name: example3


---


apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: webhook3
  annotations:
    cert-manager.io/inject-apiserver-ca: "true"
webhooks:
- name: webhook3.example.com
  admissionReviewVersions:
  - v1
  clientConfig:
    service:
      name: webhook3
      namespace: example3
      path: /validate
      port: 443
  sideEffects: None

caBundleの値が、KubeConfigファイルで使用されているCAと同一になっているはずです。

kubectl get validatingwebhookconfigurations.admissionregistration.k8s.io webhook3 -o yaml | grep caBundle
kubectl config  view --minify --raw | grep certificate-authority-data

そして、しばらくすると、Kubernetes APIサーバーはその新しいcaBundle値を読み取り、それを使用してWebhookサーバーへのTLS接続を検証します。

注: この場合、WebhookがKubernetesクラスターCAによって署名されたTLS証明書を提供するように構成されていることを確認する必要があります。このメカニズムの欠点は、KubernetesクラスターCAの秘密鍵へのアクセスが必要になることと、Webhook証明書を手動でローテーションする必要があることです。