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-idgcloud 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.comkubectl 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/v1kind: Issuermetadata:name: example-issuerspec:acme:...solvers:- dns01:cloudDNS:# The ID of the GCP projectproject: $PROJECT_ID# This is the secret used to access the service accountserviceAccountSecretRef:name: clouddns-dns01-solver-svc-acctkey: key.json
発行者(Issuers)
とクラスタ発行者(ClusterIssuers)
の詳細については、設定を参照してください。
発行者(Issuer)
(またはクラスタ発行者(ClusterIssuer)
)が正常に作成されたら、証明書(Certificate)
を追加して、すべてが機能していることを確認できます。
apiVersion: cert-manager.io/v1kind: Certificatemetadata:name: example-comnamespace: defaultspec:secretName: example-com-tlsissuerRef:# The issuer created previouslyname: example-issuerdnsNames:- 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
フラグを設定します。
GCP での KSA と GSA のリンク
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
はサービスアカウントの名前です。
Kubernetes で KSA と GSA をリンクする
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/v1kind: Issuermetadata:name: example-issuerspec:acme:...solvers:- dns01:cloudDNS:# The ID of the GCP projectproject: $PROJECT_ID
発行者(Issuers)
とクラスタ発行者(ClusterIssuers)
の詳細については、設定を参照してください。
発行者(Issuer)
(またはクラスタ発行者(ClusterIssuer)
)が正常に作成されたら、証明書(Certificate)
を追加して、すべてが機能していることを確認できます。
apiVersion: cert-manager.io/v1kind: Certificatemetadata:name: example-comnamespace: defaultspec:secretName: example-com-tlsissuerRef:# The issuer created previouslyname: example-issuerdnsNames:- example.com- www.example.com
証明書(Certificates)
の詳細については、使用方法を参照してください。