サポートコンソール開発者トライアルの開始お問い合わせ

9.4. ACME 発行者の設定

cert-manager Operator for Red Hat OpenShift は、Let's Encrypt などの Automated Certificate Management Environment (ACME) CA サーバーを使用して証明書を発行します。明示的な認証情報は、Issuer API オブジェクトにシークレットの詳細を指定して設定されます。アンビエント認証情報は、Issuer API オブジェクトで明示的に設定されていない環境、メタデータサービス、またはローカルファイルから抽出されます。

注記

Issuer オブジェクトのスコープは namespace です。同じ namespace からのみ証明書を発行できます。ClusterIssuer オブジェクトを使用して、クラスター内のすべての namespace で証明書を発行することもできます。

ClusterIssuer オブジェクトを定義する YAML ファイル例

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: acme-cluster-issuer
spec:
  acme:
    ...

注記

デフォルトで、ClusterIssuer オブジェクトをアンビエント認証情報と共に使用できます。Issuer オブジェクトをアンビエント認証情報で使用するには、cert-manager コントローラーの --issuer-ambient-credentials 設定を有効にする必要があります。

9.4.1. ACME 発行者について

cert-manager Operator for Red Hat OpenShift の ACME 発行者タイプは、Automated Certificate Management Environment (ACME) 認証局 (CA) サーバーを表します。ACME CA サーバーは、証明書が要求されているドメイン名をクライアントが所有していることを確認する チャレンジ に依存しています。チャレンジが成功すると、cert-manager Operator for Red Hat OpenShift が証明書を発行できます。チャレンジが失敗すると、cert-manager Operator for Red Hat OpenShift は証明書を発行しません。

注記

プライベート DNS ゾーンは、Let's Encrypt および internet ACME サーバーではサポートされません。

9.4.1.1. サポートされている ACME チャレンジタイプ

cert-manager Operator for Red Hat OpenShift は、ACME 発行者の次のチャレンジタイプをサポートします。

HTTP-01

HTTP-01 challenge タイプでは、ドメインの HTTP URL エンドポイントで計算されたキーを提供します。ACME CA サーバーが URL からキーを取得できる場合は、ドメインの所有者であることを確認できます。

詳細は、アップストリームの cert-manager ドキュメントの HTTP01 を参照してください。

注記

HTTP-01 では、Let's Encrypt サーバーがクラスターのルートにアクセスできる必要があります。内部クラスターまたはプライベートクラスターがプロキシーの背後にある場合、証明書発行の HTTP-01 検証は失敗します。

HTTP-01 challenge はポート 80 に制限されています。詳細は、HTTP-01 challenge (Let’s Encrypt) を参照してください。

DNS-01

DNS-01 チャレンジタイプでは、DNS TXT レコードで計算キーを提供します。ACME CA サーバーが DNS ルックアップによってキーを取得できる場合は、ドメインの所有者であることを確認できます。

詳細は、アップストリームの cert-manager ドキュメントの DNS01 を参照してください。

9.4.1.2. サポートされている DNS-01 プロバイダー

cert-manager Operator for Red Hat OpenShift は、ACME 発行者の次の DNS-01 プロバイダーをサポートします。

  • Amazon Route 53

  • Azure DNS

    注記

    cert-manager Operator for Red Hat OpenShift は、Microsoft Entra ID Pod ID を使用して Pod にマネージドアイデンティティーを割り当てることをサポートしていません。

  • Google Cloud DNS

  • Webhook

    Red Hat は、cert-manager on OpenShift Container Platform と外部 webhook を使用して、DNS プロバイダーをテストおよびサポートします。次の DNS プロバイダーは OpenShift Container Platform でテストされ、サポートされています。

    注記

    リストされていない DNS プロバイダーを使用しても OpenShift Container Platform で動作する可能性はありますが、そのプロバイダーは Red Hat でテストされていないため、Red Hat サポートの対象には含まれません。

9.4.2. HTTP-01 チャレンジを解決するための ACME 発行者の設定

cert-manager Operator for Red Hat OpenShift を使用して、ACME 発行者を設定し、HTTP-01 チャレンジを解決できます。この手順では、Let’s Encrypt を ACME CA サーバーとして使用します。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • 公開したいサービスがあります。この手順では、サービスの名前は sample-workload です。

手順

  1. ACME クラスター発行者を作成します。

    1. ClusterIssuer オブジェクトを定義する YAML ファイルを作成します。

      acme-cluster-issuer.yaml ファイルの例

      apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging                                        1
spec:
  acme:
    preferredChain: ""
    privateKeySecretRef:
      name: <secret_for_private_key>                               2
    server: https://acme-staging-v02.api.letsencrypt.org/directory 3
    solvers:
    - http01:
        ingress:
          ingressClassName: openshift-default                                 4

      1
      クラスター発行者の名前を指定します。
      2
      <secret_private_key> を ACME アカウントの秘密鍵を保存するシークレットの名前に置き換えます。
      3
      ACME サーバーの directory エンドポイントにアクセスするための URL を指定します。この例では、Let's Encrypt ステージング環境を使用します。
      4
      Ingress クラスを指定します。

    2. オプション: ingressClassName を指定せずにオブジェクトを作成する場合は、次のコマンドを使用して既存の Ingress にパッチを適用します。 

      $ oc patch ingress/<ingress-name> --type=merge --patch '{"spec":{"ingressClassName":"openshift-default"}}' -n <namespace>

    3. 次のコマンドを実行して、ClusterIssuer オブジェクトを作成します。 

      $ oc create -f acme-cluster-issuer.yaml

  2. Ingress を作成して、ユーザーワークロードのサービスを公開します。

    1. Namespace オブジェクトを定義する YAML ファイルを作成します。

      namespace.yaml ファイルの例

      apiVersion: v1
kind: Namespace
metadata:
  name: my-ingress-namespace 1

      1
      Ingress の namespace を指定します。

    2. 次のコマンドを実行して、Namespace オブジェクトを作成します。 

      $ oc create -f namespace.yaml

    3. Ingress オブジェクトを定義する YAML ファイルを作成します。

      ingress.yaml ファイルの例

      apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sample-ingress                                           1
  namespace: my-ingress-namespace                                2
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-staging          3
    acme.cert-manager.io/http01-ingress-class: openshift-default 4
spec:
  ingressClassName: openshift-default                            5
  tls:
  - hosts:
    - <hostname>                                                 6
    secretName: sample-tls                                       7
  rules:
  - host: <hostname>                                             8
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: sample-workload                                9
            port:
              number: 80

      1
      Ingress の名前を指定します。
      2
      Ingress 用に作成した namespace を指定します。
      3
      作成したクラスター発行者を指定します。
      4
      Ingress クラスを指定します。
      5
      Ingress クラスを指定します。
      6
      <hostname> を証明書に関連付けるサブジェクトの別名に置き換えます。この名前は、DNS 名を証明書に追加するために使用されます。
      7
      作成した証明書を保存するシークレットを指定します。
      8
      <hostname> をホスト名に置き換えます。<host_name>.<cluster_ingress_domain> 構文を使用して、*.<cluster_ingress_domain> ワイルドカード DNS レコードとクラスターのサービング証明書を利用できます。たとえば、apps.<cluster_base_domain> を使用できます。それ以外の場合は、選択したホスト名の DNS レコードが存在することを確認する必要があります。
      9
      公開するサービスの名前を指定します。この例では、sample-workload という名前のサービスを使用しています。

    4. 次のコマンドを実行して、Ingress オブジェクトを作成します。 

      $ oc create -f ingress.yaml

9.4.3. AWS Route53 の明示的な認証情報を使用した ACME 発行者の設定

cert-manager Operator for Red Hat OpenShift を使用して自動証明書管理環境 (ACME) 発行者を設定し、AWS で明示的な認証情報を使用して DNS-01 チャレンジを解決できます。この手順では、Let's Encrypt を ACME 認証局 (CA) サーバーとして使用し、Amazon Route 53 で DNS-01 チャレンジを解決する方法を示します。

前提条件

  • 明示的な accessKeyID および secretAccessKey 認証情報を指定する。詳細は、アップストリームの cert-manager ドキュメントの Route53 を参照してください。

    注記

    AWS で実行されていない OpenShift Container Platform クラスターで明示的な認証情報を指定して Amazon Route 53 を使用できる。

手順

  1. オプション: DNS-01 セルフチェックのネームサーバー設定をオーバーライドします。

    この手順は、ターゲットのパブリックホストゾーンがクラスターのデフォルトのプライベートホストゾーンに重複する場合のみ、必要です。

    1. 次のコマンドを実行して、CertManager リソースを編集します。 

      $ oc edit certmanager cluster

    2. 次のオーバーライド引数を指定して、spec.controllerConfig セクションを追加します。 

      apiVersion: operator.openshift.io/v1alpha1
kind: CertManager
metadata:
  name: cluster
  ...
spec:
  ...
  controllerConfig:                                1
    overrideArgs:
      - '--dns01-recursive-nameservers-only'       2
      - '--dns01-recursive-nameservers=1.1.1.1:53' 3
      1
      spec.controllerConfig セクションを追加します。
      2
      そのドメインに関連付けられた権限のあるネームサーバーをチェックする代わりに、再帰的なネームサーバーのみを使用するように指定します。
      3
      DNS-01 セルフチェックをクエリーする <host>:<port> ネームサーバーのコンマ区切りリストを提供します。パブリックゾーンとプライベートゾーンの重複を避けるには、1.1.1.1:53 値を使用する必要があります。
    3. 変更を適用するためにファイルを保存します。

  2. オプション: 発行者の namespace を作成します。 

    $ oc new-project <issuer_namespace>

  3. 次のコマンドを実行して、AWS 認証情報を保存するシークレットを作成します。 

    $ oc create secret generic aws-secret --from-literal=awsSecretAccessKey=<aws_secret_access_key> \ 1
    -n my-issuer-namespace
    1
    <aws_secret_access_key> を AWS シークレットアクセスキーに置き換えます。

  4. 発行者を作成します。

    1. Issuer オブジェクトを定義する YAML ファイルを作成します。

      issuer.yaml ファイルの例

      apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: <letsencrypt_staging>                                        1
  namespace: <issuer_namespace>                                   2
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory 3
    email: "<email_address>"                                       4
    privateKeySecretRef:
      name: <secret_private_key>                                   5
    solvers:
    - dns01:
        route53:
          accessKeyID: <aws_key_id>                                6
          hostedZoneID: <hosted_zone_id>                           7
          region: <region_name>                                    8
          secretAccessKeySecretRef:
            name: "aws-secret"                                     9
            key: "awsSecretAccessKey"                              10

      1
      発行者の名前を指定します。
      2
      発行者用に作成した namespace を指定します。
      3
      ACME サーバーの directory エンドポイントにアクセスするための URL を指定します。この例では、Let's Encrypt ステージング環境を使用します。
      4
      <email_address> を自分のメールアドレスに置き換えます。
      5
      <secret_private_key> を ACME アカウントの秘密鍵を保存するシークレットの名前に置き換えます。
      6
      <aws_key_id> を AWS キー ID に置き換えます。
      7
      <hosted_zone_id> をホストゾーン ID に置き換えます。
      8
      <region_name> は、AWS リージョン名に置き換えます。たとえば、us-east-1 などです。
      9
      作成したシークレットの名前を指定します。
      10
      AWS シークレットアクセスキーを保存する、作成したシークレットのキーを指定します。

    2. 次のコマンドを実行して、Issuer オブジェクトを作成します。 

      $ oc create -f issuer.yaml

9.4.4. AWS でアンビエント認証情報を使用した ACME 発行者の設定

cert-manager Operator for Red Hat OpenShift を使用して、AWS 上のアンビエント認証情報を使用して DNS-01 チャレンジを解決する ACME 発行者を設定できます。この手順では、Let's Encrypt を ACME CA サーバーとして使用し、Amazon Route 53 で DNS-01 チャレンジを解決する方法を示します。

前提条件

  • クラスターが AWS Security Token Service (STS) を使用するように設定されている場合は、AWS Security Token Service クラスターの cert-manager Operator for Red Hat OpenShift のクラウド認証情報の設定 セクションの手順に従っている。
  • クラスターで AWS STS を使用しない場合は、AWS での the cert-manager Operator for Red Hat OpenShift クラウド認証情報の設定 セクションの手順に従っている。

手順

  1. オプション: DNS-01 セルフチェックのネームサーバー設定をオーバーライドします。

    この手順は、ターゲットのパブリックホストゾーンがクラスターのデフォルトのプライベートホストゾーンに重複する場合のみ、必要です。

    1. 次のコマンドを実行して、CertManager リソースを編集します。 

      $ oc edit certmanager cluster

    2. 次のオーバーライド引数を指定して、spec.controllerConfig セクションを追加します。 

      apiVersion: operator.openshift.io/v1alpha1
kind: CertManager
metadata:
  name: cluster
  ...
spec:
  ...
  controllerConfig:                                1
    overrideArgs:
      - '--dns01-recursive-nameservers-only'       2
      - '--dns01-recursive-nameservers=1.1.1.1:53' 3
      1
      spec.controllerConfig セクションを追加します。
      2
      そのドメインに関連付けられた権限のあるネームサーバーをチェックする代わりに、再帰的なネームサーバーのみを使用するように指定します。
      3
      DNS-01 セルフチェックをクエリーする <host>:<port> ネームサーバーのコンマ区切りリストを提供します。パブリックゾーンとプライベートゾーンの重複を避けるには、1.1.1.1:53 値を使用する必要があります。
    3. 変更を適用するためにファイルを保存します。

  2. オプション: 発行者の namespace を作成します。 

    $ oc new-project <issuer_namespace>

  3. CertManager リソースを変更して、--issuer-ambient-credentials 引数を追加します。 

    $ oc patch certmanager/cluster \
  --type=merge \
  -p='{"spec":{"controllerConfig":{"overrideArgs":["--issuer-ambient-credentials"]}}}'

  4. 発行者を作成します。

    1. Issuer オブジェクトを定義する YAML ファイルを作成します。

      issuer.yaml ファイルの例

      apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: <letsencrypt_staging>                                        1
  namespace: <issuer_namespace>                                   2
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory 3
    email: "<email_address>"                                       4
    privateKeySecretRef:
      name: <secret_private_key>                                   5
    solvers:
    - dns01:
        route53:
          hostedZoneID: <hosted_zone_id>                           6
          region: us-east-1

      1
      発行者の名前を指定します。
      2
      発行者用に作成した namespace を指定します。
      3
      ACME サーバーの directory エンドポイントにアクセスするための URL を指定します。この例では、Let's Encrypt ステージング環境を使用します。
      4
      <email_address> を自分のメールアドレスに置き換えます。
      5
      <secret_private_key> を ACME アカウントの秘密鍵を保存するシークレットの名前に置き換えます。
      6
      <hosted_zone_id> をホストゾーン ID に置き換えます。

    2. 次のコマンドを実行して、Issuer オブジェクトを作成します。 

      $ oc create -f issuer.yaml

9.4.5. GCP Cloud DNS の明示的な認証情報を使用した ACME 発行者の設定

cert-manager Operator for Red Hat OpenShift を使用して ACME 発行者を設定し、GCP で明示的な認証情報を使用して DNS-01 チャレンジを解決できます。この手順では、Let's Encrypt を ACME CA サーバーとして使用し、Google CloudDNS を使用して DNS-01 の課題を解決する方法を示します。

前提条件

  • Google CloudDNS に必要なロールで Google Cloud サービスアカウントを設定している。詳細は、アップストリームの cert-manager ドキュメントの Google CloudDNS を参照してください。

    注記

    GCP で実行されていない OpenShift Container Platform クラスター内の明示的な認証情報で Google CloudDNS を使用できます。

手順

  1. オプション: DNS-01 セルフチェックのネームサーバー設定をオーバーライドします。

    この手順は、ターゲットのパブリックホストゾーンがクラスターのデフォルトのプライベートホストゾーンに重複する場合のみ、必要です。

    1. 次のコマンドを実行して、CertManager リソースを編集します。 

      $ oc edit certmanager cluster

    2. 次のオーバーライド引数を指定して、spec.controllerConfig セクションを追加します。 

      apiVersion: operator.openshift.io/v1alpha1
kind: CertManager
metadata:
  name: cluster
  ...
spec:
  ...
  controllerConfig:                                1
    overrideArgs:
      - '--dns01-recursive-nameservers-only'       2
      - '--dns01-recursive-nameservers=1.1.1.1:53' 3
      1
      spec.controllerConfig セクションを追加します。
      2
      そのドメインに関連付けられた権限のあるネームサーバーをチェックする代わりに、再帰的なネームサーバーのみを使用するように指定します。
      3
      DNS-01 セルフチェックをクエリーする <host>:<port> ネームサーバーのコンマ区切りリストを提供します。パブリックゾーンとプライベートゾーンの重複を避けるには、1.1.1.1:53 値を使用する必要があります。
    3. 変更を適用するためにファイルを保存します。

  2. オプション: 発行者の namespace を作成します。 

    $ oc new-project my-issuer-namespace

  3. 次のコマンドを実行して、GCP 認証情報を保存するためのシークレットを作成します。 

    $ oc create secret generic clouddns-dns01-solver-svc-acct --from-file=service_account.json=<path/to/gcp_service_account.json> -n my-issuer-namespace

  4. 発行者を作成します。

    1. Issuer オブジェクトを定義する YAML ファイルを作成します。

      issuer.yaml ファイルの例

      apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: <acme_dns01_clouddns_issuer> 1
  namespace: <issuer_namespace> 2
spec:
  acme:
    preferredChain: ""
    privateKeySecretRef:
      name: <secret_private_key> 3
    server: https://acme-staging-v02.api.letsencrypt.org/directory 4
    solvers:
    - dns01:
        cloudDNS:
          project: <project_id> 5
          serviceAccountSecretRef:
            name: clouddns-dns01-solver-svc-acct 6
            key: service_account.json 7

      1
      発行者の名前を指定します。
      2
      <issuer_namespace> は、発行者の namespace に置き換えます。
      3
      <secret_private_key> を ACME アカウントの秘密鍵を保存するシークレットの名前に置き換えます。
      4
      ACME サーバーの directory エンドポイントにアクセスするための URL を指定します。この例では、Let's Encrypt ステージング環境を使用します。
      5
      <project_id> は、Cloud DNS ゾーンを含む GCP プロジェクトの名前に置き換えます。
      6
      作成したシークレットの名前を指定します。
      7
      GCP シークレットアクセスキーを保存する、作成したシークレットのキーを指定します。

    2. 次のコマンドを実行して、Issuer オブジェクトを作成します。 

      $ oc create -f issuer.yaml

9.4.6. GCP でのアンビエント認証情報を使用した ACME 発行者の設定

cert-manager Operator for Red Hat OpenShift を使用して ACME 発行者を設定し、GCP でアンビエント認証情報を使用することで DNS-01 チャレンジを解決できます。この手順では、Let's Encrypt を ACME CA サーバーとして使用し、Google CloudDNS を使用して DNS-01 の課題を解決する方法を示します。

前提条件

  • クラスターが GCP Workload Identity を使用するように 設定されている場合は、GCP ワークロード ID を使用した cert-manager Operator for Red Hat OpenShift の設定 セクションの手順に従う。
  • クラスターが GCP Workload Identity を使用しない場合は、GCP での the cert-manager Operator for Red Hat OpenShift クラウド認証情報の設定 セクションの手順に従う。

手順

  1. オプション: DNS-01 セルフチェックのネームサーバー設定をオーバーライドします。

    この手順は、ターゲットのパブリックホストゾーンがクラスターのデフォルトのプライベートホストゾーンに重複する場合のみ、必要です。

    1. 次のコマンドを実行して、CertManager リソースを編集します。 

      $ oc edit certmanager cluster

    2. 次のオーバーライド引数を指定して、spec.controllerConfig セクションを追加します。 

      apiVersion: operator.openshift.io/v1alpha1
kind: CertManager
metadata:
  name: cluster
  ...
spec:
  ...
  controllerConfig:                                1
    overrideArgs:
      - '--dns01-recursive-nameservers-only'       2
      - '--dns01-recursive-nameservers=1.1.1.1:53' 3
      1
      spec.controllerConfig セクションを追加します。
      2
      そのドメインに関連付けられた権限のあるネームサーバーをチェックする代わりに、再帰的なネームサーバーのみを使用するように指定します。
      3
      DNS-01 セルフチェックをクエリーする <host>:<port> ネームサーバーのコンマ区切りリストを提供します。パブリックゾーンとプライベートゾーンの重複を避けるには、1.1.1.1:53 値を使用する必要があります。
    3. 変更を適用するためにファイルを保存します。

  2. オプション: 発行者の namespace を作成します。 

    $ oc new-project <issuer_namespace>

  3. CertManager リソースを変更して、--issuer-ambient-credentials 引数を追加します。 

    $ oc patch certmanager/cluster \
  --type=merge \
  -p='{"spec":{"controllerConfig":{"overrideArgs":["--issuer-ambient-credentials"]}}}'

  4. 発行者を作成します。

    1. Issuer オブジェクトを定義する YAML ファイルを作成します。

      issuer.yaml ファイルの例

      apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: <acme_dns01_clouddns_issuer> 1
  namespace: <issuer_namespace>
spec:
  acme:
    preferredChain: ""
    privateKeySecretRef:
      name: <secret_private_key> 2
    server: https://acme-staging-v02.api.letsencrypt.org/directory 3
    solvers:
    - dns01:
        cloudDNS:
          project: <gcp_project_id> 4

      1
      発行者の名前を指定します。
      2
      <secret_private_key> を ACME アカウントの秘密鍵を保存するシークレットの名前に置き換えます。
      3
      ACME サーバーの directory エンドポイントにアクセスするための URL を指定します。この例では、Let's Encrypt ステージング環境を使用します。
      4
      <gcp_project_id> は、Cloud DNS ゾーンを含む GCP プロジェクトの名前に置き換えます。

    2. 次のコマンドを実行して、Issuer オブジェクトを作成します。 

      $ oc create -f issuer.yaml

9.4.7. Microsoft Azure DNS の明示的な認証情報を使用した ACME 発行者の設定

cert-manager Operator for Red Hat OpenShift を使用して ACME 発行者を設定し、Microsoft Azure で明示的な認証情報を使用して DNS-01 チャレンジを解決できます。この手順では、Let’s Encrypt を ACME CA サーバーとして使用し、Azure DNS で DNS-01 チャレンジを解決する方法を示します。

前提条件

  • Azure DNS に必要なロールでサービスプリンシパルを設定している。詳細は、アップストリームの cert-manager ドキュメントの Azure DNS を参照してください。

    注記

    Microsoft Azure で実行されていない OpenShift Container Platform クラスターについては、以下の手順を実行できます。

手順

  1. オプション: DNS-01 セルフチェックのネームサーバー設定をオーバーライドします。

    この手順は、ターゲットのパブリックホストゾーンがクラスターのデフォルトのプライベートホストゾーンに重複する場合のみ、必要です。

    1. 次のコマンドを実行して、CertManager リソースを編集します。 

      $ oc edit certmanager cluster

    2. 次のオーバーライド引数を指定して、spec.controllerConfig セクションを追加します。 

      apiVersion: operator.openshift.io/v1alpha1
kind: CertManager
metadata:
  name: cluster
  ...
spec:
  ...
  controllerConfig:                                1
    overrideArgs:
      - '--dns01-recursive-nameservers-only'       2
      - '--dns01-recursive-nameservers=1.1.1.1:53' 3
      1
      spec.controllerConfig セクションを追加します。
      2
      そのドメインに関連付けられた権限のあるネームサーバーをチェックする代わりに、再帰的なネームサーバーのみを使用するように指定します。
      3
      DNS-01 セルフチェックをクエリーする <host>:<port> ネームサーバーのコンマ区切りリストを提供します。パブリックゾーンとプライベートゾーンの重複を避けるには、1.1.1.1:53 値を使用する必要があります。
    3. 変更を適用するためにファイルを保存します。

  2. オプション: 発行者の namespace を作成します。 

    $ oc new-project my-issuer-namespace

  3. 次のコマンドを実行して、Azure 認証情報を保存するシークレットを作成します。 

    $ oc create secret generic <secret_name> --from-literal=<azure_secret_access_key_name>=<azure_secret_access_key_value> \ 1 2 3
    -n my-issuer-namespace
    1
    <secret_name> は、シークレット名に置き換えます。
    2
    <azure_secret_access_key_name> は、Azure シークレットアクセスキーの名前に置き換えます。
    3
    <azure_secret_access_key_value> は、Azure 秘密鍵に置き換えます。

  4. 発行者を作成します。

    1. Issuer オブジェクトを定義する YAML ファイルを作成します。

      issuer.yaml ファイルの例

      apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: <acme-dns01-azuredns-issuer>   1
  namespace: <issuer_namespace>   2
spec:
  acme:
    preferredChain: ""
    privateKeySecretRef:
      name: <secret_private_key> 3
    server: https://acme-staging-v02.api.letsencrypt.org/directory 4
    solvers:
    - dns01:
        azureDNS:
          clientID: <azure_client_id> 5
          clientSecretSecretRef:
            name: <secret_name> 6
            key: <azure_secret_access_key_name> 7
          subscriptionID: <azure_subscription_id> 8
          tenantID: <azure_tenant_id> 9
          resourceGroupName: <azure_dns_zone_resource_group> 10
          hostedZoneName: <azure_dns_zone> 11
          environment: AzurePublicCloud

      1
      発行者の名前を指定します。
      2
      <issuer_namespace> は、発行者の namespace に置き換えます。
      3
      <secret_private_key> を ACME アカウントの秘密鍵を保存するシークレットの名前に置き換えます。
      4
      ACME サーバーの directory エンドポイントにアクセスするための URL を指定します。この例では、Let's Encrypt ステージング環境を使用します。
      5
      <azure_client_id> は Azure クライアント ID に置き換えます。
      6
      <secret_name> はクライアントシークレットの名前に置き換えます。
      7
      <azure_secret_access_key_name> は、クライアントシークレットキーの名前に置き換えます。
      8
      <azure_subscription_id> は、Azure サブスクリプション ID に置き換えます。
      9
      <azure_tenant_id> は Azure テナント ID に置き換えます。
      10
      <azure_dns_zone_resource_group> は Azure DNS ゾーンリソースグループの名前に置き換えます。
      11
      <azure_dns_zone> は Azure DNS ゾーンの名前に置き換えます。

    2. 次のコマンドを実行して、Issuer オブジェクトを作成します。 

      $ oc create -f issuer.yaml

9.4.8. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.