新機能:プロジェクトの最新情報はこちらで入手できます TwitterMastodon

Google CloudDNS

このガイドでは、Google CloudDNS を使用して DNS01 ACME チャレンジを解決するための発行者(Issuer)またはクラスタ発行者(ClusterIssuer)の設定方法について説明します。 cert-manager が DNS01 チャレンジをどのように処理するかについて、より一般的な理解を得るために、まずDNS01 チャレンジプロバイダのページを読むことをお勧めします。

このガイドでは、クラスタが Google Cloud Platform (GCP) 上でホストされており、CloudDNS を使用してドメインが既に設定されていることを前提としています。

ACME チャレンジチェッカーが cert-manager が作成する DNS レコードにアクセスできるように、**パブリック DNS ゾーン**を使用する必要があります。

サービスアカウントの設定

cert-manager は、DNS01 チャレンジを解決するために CloudDNS にレコードを追加できる必要があります。これを実現するには、dns.admin ロールを持つ GCP サービスアカウントを作成する必要があります。

注:このガイドでは、サービスアカウントの設定にgcloudコマンドを使用します。gcloudが正しいプロジェクトとゾーンを使用していることを確認してから、コマンドを入力してください。これらの手順は、Cloud Console を使用して完了することもできます。

PROJECT_ID=myproject-id
gcloud iam service-accounts create dns01-solver --display-name "dns01-solver"

上記のコマンドでは、myproject-idをプロジェクトのIDに置き換えてください。

gcloud projects add-iam-policy-binding $PROJECT_ID \
--member serviceAccount:dns01-solver@$PROJECT_ID.iam.gserviceaccount.com \
--role roles/dns.admin

:この例でdns.adminロールを使用するのは、便宜上です。cert-manager を最小権限のサービスアカウントで実行する場合は、次の権限を持つカスタムロールを作成する必要があります。

  • dns.resourceRecordSets.*
  • dns.changes.*
  • dns.managedZones.list

dns.adminロールを使用しない場合、GKEクラスタで使用されるサービスアカウント(例:Compute Engineのデフォルトサービスアカウント)にhttps://www.googleapis.com/auth/cloud-platformアクセススコープが割り当てられていることを確認する必要があります。GKE のアクセススコープを参照してください。

静的資格情報の使用

次のセクションの手順に従って、作成したサービスアカウントの静的資格情報を使用して cert-manager をデプロイします。これらの資格情報は定期的にローテーションする必要があります。

サービスアカウントシークレットの作成

このサービスアカウントにアクセスするために、cert-manager は Kubernetes シークレット(Secret)に保存されているキーを使用します。まず、サービスアカウントのキーを作成し、JSONファイルとしてダウンロードしてから、このファイルからシークレット(Secret)を作成します。

キーファイルは安全に保管し、共有しないでください。共有すると、クラウドリソースへのアクセス権を取得される可能性があります。キーファイルは、シークレット(Secret)の生成に使用された後は削除できます。

事前にサービスアカウントdns01-solverを作成していない場合は、最初に作成する必要があります。

gcloud iam service-accounts create dns01-solver

$PROJECT_IDのインスタンスをプロジェクトのIDに置き換えてください。

gcloud iam service-accounts keys create key.json \
--iam-account dns01-solver@$PROJECT_ID.iam.gserviceaccount.com
kubectl create secret generic clouddns-dns01-solver-svc-acct \
--from-file=key.json

注:シークレット(Secret)を既に追加したが、エラーが発生した場合:...due to error processing: error getting clouddns service account: secret "XXX" not foundシークレット(Secret)が間違った名前空間に存在する可能性があります。クラスタ発行者(ClusterIssuer)を設定している場合は、シークレット(Secret)をデフォルトでcert-managerであるクラスタリソース名前空間に移動します。発行者(Issuer)を設定している場合は、シークレット(Secret)発行者(Issuer)リソースと同じ名前空間に保存する必要があります。

CloudDNS を使用する発行者の作成

次に、cloudDNSプロバイダを使用して発行者(Issuer)(またはクラスタ発行者(ClusterIssuer))を作成します。注釈付きの発行者(Issuer)マニフェストの例を以下に示します。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: example-issuer
spec:
acme:
...
solvers:
- dns01:
cloudDNS:
# The ID of the GCP project
project: $PROJECT_ID
# This is the secret used to access the service account
serviceAccountSecretRef:
name: clouddns-dns01-solver-svc-acct
key: key.json

発行者(Issuers)クラスタ発行者(ClusterIssuers)の詳細については、設定を参照してください。

発行者(Issuer)(またはクラスタ発行者(ClusterIssuer))が正常に作成されたら、証明書(Certificate)を追加して、すべてが機能していることを確認できます。

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-com
namespace: default
spec:
secretName: example-com-tls
issuerRef:
# The issuer created previously
name: example-issuer
dnsNames:
- example.com
- www.example.com

証明書(Certificates)の詳細については、使用方法を参照してください。

GKE ワークロードアイデンティティ

ワークロードアイデンティティが有効になっているGoogle Kubernetes Engine (GKE) クラスタに cert-manager をデプロイする場合は、ワークロードアイデンティティを利用して、静的サービスアカウント資格情報の作成と管理を回避できます。ワークロードアイデンティティのハウツーでは、ワークロードアイデンティティの機能について詳しく説明していますが、簡単に言うと、ワークロードアイデンティティにより、Googleサービスアカウント(GSA)をKubernetesサービスアカウント(KSA)にリンクできます。このGSA/KSAのリンクは双方向です。つまり、GCPとKubernetesの両方でリンクを確立する必要があります。設定が完了すると、ワークロードアイデンティティにより、KSAで実行されているKubernetesポッドは、リンクされたGSAの権限を使用してGCP APIにアクセスできます。ワークロードアイデンティティのハウツーには、GKEクラスタでワークロードアイデンティティを有効にする方法についても詳細な手順が記載されています。次のセクションの手順では、ワークロードアイデンティティが既に有効になっているGKEクラスタにcert-managerをデプロイすることを前提としています。

環境資格情報の使用の有効化

「環境資格情報」とは、ClusterIssuer APIオブジェクトで明示的に設定されていない環境、メタデータサービス、またはローカルファイルから取得される資格情報です。このフラグが有効になっている場合、Cert-Managerは資格情報のためにGKEメタデータサーバーにアクセスします。デフォルトでは、ClusterIssuerリソースに対して有効になっていますが、Issuerリソースに対しては無効になっています。Issuerリソースに対して有効にするには、--issuer-ambient-credentialsフラグを設定します。

DNSレコードを変更する必要があるcert-managerコンポーネントは、cert-managerデプロイの一部として作成されたポッドです。Kubernetesへのcert-managerの標準的なデプロイ方法は、cert-manager名前空間にcert-managerデプロイを作成し、そのポッド仕様はcert-managerサービスアカウントで実行されることを指定しています。上記で作成したGSAをGKEクラスタのcert-manager名前空間にcert-manager KSAにリンクするには、次のコマンドを実行します。

gcloud iam service-accounts add-iam-policy-binding \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:$PROJECT_ID.svc.id.goog[cert-manager/cert-manager]" \
dns01-solver@$PROJECT_ID.iam.gserviceaccount.com

cert-managerポッドが別のサービスアカウントで実行されている場合は、goog[cert-manager/cert-manager]goog[NAMESPACE/SERVICE_ACCOUNT]に置き換えます。ここで、NAMESPACEはサービスアカウントの名前空間、SERVICE_ACCOUNTはサービスアカウントの名前です。

cert-manager をデプロイした後、cert-manager サービスアカウントに適切なワークロードアイデンティティアノテーションを追加します。

kubectl annotate serviceaccount --namespace=cert-manager cert-manager \
"iam.gke.io/gcp-service-account=dns01-solver@$PROJECT_ID.iam.gserviceaccount.com"

再度、cert-manager ポッドが別のサービスアカウントで実行されている場合は、--namespace=cert-manager cert-manager--namespace=NAMESPACE SERVICE_ACCOUNT に置き換えます。NAMESPACE はサービスアカウントの名前空間、SERVICE_ACCOUNT はサービスアカウントの名前です。

Helm チャートを使用して cert-manager をデプロイする場合は、serviceAccount.annotations 構成パラメーターを使用して、上記のワークロードアイデンティティアノテーションを cert-manager KSA に追加できます。

CloudDNS を使用する Issuer を作成する

次に、clouddns プロバイダーを使用して Issuer(または ClusterIssuer)を作成します。アノテーション付きの Issuer マニフェストの例を以下に示します。Issuer には serviceAccountSecretRef プロパティが含まれていません。これを除外することで、cert-manager は GKE ワークロードアイデンティティによって提供されるデフォルトの資格情報を使用するように指示されます。

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: example-issuer
spec:
acme:
...
solvers:
- dns01:
cloudDNS:
# The ID of the GCP project
project: $PROJECT_ID

発行者(Issuers)クラスタ発行者(ClusterIssuers)の詳細については、設定を参照してください。

発行者(Issuer)(またはクラスタ発行者(ClusterIssuer))が正常に作成されたら、証明書(Certificate)を追加して、すべてが機能していることを確認できます。

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-com
namespace: default
spec:
secretName: example-com-tls
issuerRef:
# The issuer created previously
name: example-issuer
dnsNames:
- example.com
- www.example.com

証明書(Certificates)の詳細については、使用方法を参照してください。