概要概要
HTTPSの人気が高まるにつれ、HTTPからHTTPSにアップグレードするWebサイトが増えています。HTTPSを使用するには、当局に証明書を申請する必要があり、一定の費用を支払う必要があります。要件の数が多い場合、それも大きな費用になります。cert-managerは、Kubernetesの総合的な証明書管理ツールです。セキュリティレベルと証明書の機能が高くない場合は、cert-managerを使用してACMEプロトコルとLet's Encryptに基づいて無料の証明書を発行し、それらを自動的に更新して、証明書を永続的に無料で使用できます。
cert-managerのしくみ
cert-managerがKubernetesクラスターにデプロイされると、サポートするCRDリソースを監視します。CRDリソースを作成して、cert-managerに証明書を発行し、自動的に更新するように指示します。
次の主要なリソースについて説明します。
- Issuer / ClusterIssuer:証明書を発行する方法をcert-managerに指示するために使用されます。この記事では、主に無料の証明書を発行するACMEの方法について説明します。ClusterIssuerとIssuerの唯一の違いは、Issuerは独自の名前名で証明書を発行するためにのみ使用でき、ClusterIssuerは任意の名前名で証明書を発行できることです。
- 証明書:証明書マネージャーに、必要なドメイン名証明書と、Issuer / ClusterIssuerへの参照など、証明書を発行するために必要ないくつかの構成を通知するために使用されます。
無料の証明書発行原則
Let's Encryptは、ACMEプロトコルを使用して、ドメイン名が本当に自分のものかどうかを確認します。確認が成功すると、無料の証明書が自動的に発行されます。証明書の有効期間は90日間のみです。更新するには、有効期限が切れる前に再度確認する必要があります。幸い、証明書-managerは自動的に更新できるため、永続的な無料の証明書を使用できます。このドメイン名が自分のものかどうかを確認するにはどうすればよいですか?2つの主流の検証方法はHTTP-01とDNS-01です。詳細な検証原則については、以下で簡単に説明する「Let'sEncrypt操作方法」を参照してください。
HTTP-01検証の原則
HTTP-01パリティの原則は、ドメイン名がHTTPサービスの場所の一時的な増加を示すことです。Let'sEncrypthttpリクエストが送信されhttp:///.well-known/acme-challenge/
、YOUR_DOMAIN
ドメイン名が検証され、TOKEN
ファイルクライアントACMEがプロトコルを担当します。クライアントACMEはendはcert-managerであり、Ingressルールを変更または作成して、TOKEN
サービスを提供するための一時的なパスとチェックポイントを増やします。Let's EncryptはTOKEN
、期待に応えるものを比較し、検証が成功した後に証明書を発行します。この方法は、Ingressを使用してトラフィックを公開するサービスに証明書を発行する場合にのみ適しており、汎ドメイン証明書をサポートしていません。
DNS-01検証の原則
DNS-01の検証原則は、DNSプロバイダーのAPIキーを使用してDNS制御権限を取得することです。Let'sEncryptがACMEクライアントにトークンを提供した後、ACMEクライアント(cert-manager)がトークンを作成し、アカウントキーから派生したTXTレコードを作成し、そのレコードを配置し_acme-challenge.
ます。Let's EncryptはDNSシステムにレコードを照会し、一致するものが見つかった場合は証明書を発行できます。この方法では、サービスでIngressを使用する必要はなく、汎ドメイン証明書をサポートします。
検証方法の比較
HTTP-01検証方法の利点は、構成が単純で普遍的であり、どのDNSプロバイダーを使用しても、同じ構成方法を使用できることです。欠点は、サービスがIngressを使用してトラフィックを公開しない場合はIngressに依存する必要があり、適用できないことです。パンドメイン証明書はサポートしていません。
DNS-01検証方法の利点は、HTTP-01検証方法の欠点がなく、Ingressに依存せず、汎ドメイン名をサポートすることです。欠点は、DNSプロバイダーごとに構成方法が異なり、多くのDNSプロバイダーであるcert-managerがあることです。すべての発行者をサポートすることは不可能ですが、DNSPodやAli DNSなどのcert-managerを実装するWebhookを展開することで、発行者をサポートするように拡張できるサービスがいくつかあります。Webhookの詳細なリストについては、https:// cert-managerを参照してください。.io / docs / configuration / acme / dns01 /#webhook
どちらを選ぶのですか?条件が許せば、提案は方法の最善の使用法でDNS-01
あり、制限が少なく、より全体的です。
手順
cert-managerをインストールします
通常、yamlを使用してワンクリックで直接クラスターにcert-managerをインストールできます。公式Webサイトのドキュメント「通常のマニフェストを使用したインストール」を参照してください。
cert-managerで使用される公式ミラーが利用可能ですquay.io
。国内プルは遅い場合があります。次のコマンドを使用してワンクリックでインストールすることもできます(国内CCRに同期されたミラーを使用)。
kubectl apply --validate=false -f https://raw.githubusercontent.com/TencentCloudContainerTeam/manifest/master/cert-manager/cert-manager.yaml
!上記のコマンドのインストール方法では、クラスターのバージョンが1.16以上である必要があります。
DNSを構成する
DNSプロバイダーのバックエンドにログインし、証明書が必要なバックエンドサービスの外部に公開されたIPアドレスを指すようにドメイン名のDNSAレコードを構成します。例としてcloudflareを取り上げます。
HTTP-01検証方式発行証明書
HTTP-01検証を使用する場合は、Ingressを使用して検証に協力する必要があります。cert-managerは、外部HTTP暫定的な目的のパス検証を達成または公開するために自動的に追加されたIngress Ingressルールを自動的に変更します。これは、Ingressが指定name
またはclass
区別されたIssuer http01構成へのチェックです(以下の例を参照)。
TKEの組み込みIngressは、各IngressリソースがCLBに対応することです。TKEの組み込みIngressを使用してサービスを公開し、HTTP-01検証を使用する場合、Ingressを自動的に変更する方法のみを使用でき、Ingressを自動的に追加することはできません。 、自動的に追加されたIngressは自動的に他のCLBを作成し、外部IPアドレスがバックエンドサービスのIngressと矛盾するためです。Let’s Encryptが検証されると、検証に必要な一時パスがサービスのIngressから見つかりません。検証に失敗し、証明書を発行できませんでした。TKEでのNginxIngressの展開など、自己Ingressを使用する場合、Ingressの同じIngressクラスが同じCLBを共有するため、Ingressの方法を自動的に追加するために使用できます。
いくつかの例を以下に示します。
サービスでTKEサービスを使用する場合、Ingressが公開されます。証明書は、管理のK8Sではなく、参照する証明書管理にアップロードされるため、cert-managerで無料で証明書を発行する管理には適していません。
Nginx Ingress TKE、Ingress、およびprod/web
発行者の例を作成するバックエンドサービスに展開されると想定されます。
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt-http01
namespace: prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-http01-account-key
solvers:
- http01:
ingress:
name: web # 指定被自动修改的 Ingress 名称
上記の発行者を使用して証明書を発行すると、cert-managerはprod/web
、一時パス検証を公開するために必要なIngressリソースを自動的に変更します。これは、Ingressウェイを自動的に追加するために使用できるIngressウェイを自動的に変更します。例:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt-http01
namespace: prod
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-http01-account-key
solvers:
- http01:
ingress:
class: nginx # 指定自动创建的 Ingress 的 ingress class
上記の発行者を使用して証明書を発行すると、cert-managerが自動的にIngressリソースを作成して、検証に必要な一時パスを公開します。
発行者を使用すると、証明書を作成し、署名のために発行者を参照できます。例:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: test-mydomain-com
namespace: prod
spec:
dnsNames:
- test.mydomain.com # 要签发证书的域名
issuerRef:
kind: Issuer
name: letsencrypt-http01 # 引用 Issuer,指示采用 http01 方式进行校验
secretName: test-mydomain-com-tls # 最终签发出来的证书会保存在这个 Secret 里面
DNS-01検証方式発行証明書
DNS-01検証方法を使用する場合は、使用するDNSプロバイダーによって異なります。cert-managerには一部のDNSプロバイダーのサポートが組み込まれています。詳細なリストと使用法については、サポートされているDNS01プロバイダーを参照してください。ただし、cert-managerは使用できません。すべてのDNSプロバイダーをサポートするために、使用するDNSプロバイダーがない場合はどうなりますか?2つのオプションがあります:
-
オプション1:カスタムネームサーバーを設定します。DNSプロバイダーのバックエンドにカスタムネームサーバーを設定し、他のDNSプロバイダーのドメイン名を管理できるcloudflareなどのネームサーバーアドレスを指定します。特定のアドレスは、cloudflareバックエンドで確認できます。
以下は、カスタムネームサーバーを安価に設定する例です。
最後に、DNS-01検証を指定するように発行者を構成するときに、クラウドフレア情報を追加します(以下の例を参照)。
- オプション2:Webhookを使用します。cert-managerのWebhookを使用して、cert-managerのDNS-01検証でサポートされるDNSプロバイダーを拡張します。中国で一般的に使用されているDNSPodやAli DNSなど、多くのサードパーティの実装があります。詳細なリストについては、Webhookを参照してください。
証明書を発行する例としてcloudflareを取り上げましょう。
-
cloudflareをログに記録し、
My Profile > API Tokens > Create Token
トークンを作成するように指示します。トークンをコピーして適切に保管します。
トークンをシークレットに保存:
apiVersion: v1 kind: Secret metadata: name: cloudflare-api-token-secret namespace: cert-manager type: Opaque stringData: api-token: <API Token> # 粘贴 Token 到这里,不需要 base64 加密。
!ClusterIssuerを作成する場合は、cert-managerが配置されている名前名にシークレットを作成する必要があります。発行者の場合は、発行者が配置されている名前名に作成します。
ClusterIssuerを作成します。
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-dns01 spec: acme: privateKeySecretRef: name: letsencrypt-dns01 server: https://acme-v02.api.letsencrypt.org/directory solvers: - dns01: cloudflare: email: [email protected] # 替换成你的 cloudflare 邮箱账号,API Token 方式认证非必需,API Keys 认证是必需 apiTokenSecretRef: key: api-token name: cloudflare-api-token-secret # 引用保存 cloudflare 认证信息的 Secret
証明書の作成:
apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: test-mydomain-com namespace: default spec: dnsNames: - test.mydomain.com # 要签发证书的域名 issuerRef: kind: ClusterIssuer name: letsencrypt-dns01 # 引用 ClusterIssuer,指示采用 dns01 方式进行校验 secretName: test-mydomain-com-tls # 最终签发出来的证书会保存在这个 Secret 里面
証明書の取得と使用
証明書を作成したら、しばらく待ってから、kubectlを使用して発行が成功したかどうかを確認できます。
$ kubectl get certificate -n prod
NAME READY SECRET AGE
test-mydomain-com True test-mydomain-com-tls 1m
READY
がFalse
失敗の場合は、describeイベントを表示して失敗の原因をトラブルシューティングできます。
$ kubectl describe certificate test-mydomain-com -n prod
True
証明書の発行が成功したことを表す場合は、指定したシークレットに保存されます(上記の例はdefault/test-mydomain-com-tls
)、kubectlを表示できます。
$ kubectl get secret test-mydomain-com-tls -n default
...
data:
tls.crt: <cert>
tls.key: <private key>
これtls.crt
は証明書であり、tls.key
鍵です。
証明書を必要とするアプリケーションにそれらをマウントするか、自作のIngressを使用できます。たとえば、Ingressでシークレットを直接参照できます。
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: test-ingress
annotations:
kubernetes.io/Ingress.class: nginx
spec:
rules:
- host: test.mydomain.com
http:
paths:
- path: /web
backend:
serviceName: web
servicePort: 80
tls:
hosts:
- test.mydomain.com
secretName: test-mydomain-com-tls
概要
この記事では、cert-managerの動作原理、インストール方法、および無料の証明書を発行するための2つの検証方法(HTTP-01とDNS-01)の原理、比較、および操作方法を紹介します。
参照
- cert-manager公式ウェブサイト:https://cert-manager.io/
- Let's Encryptの仕組み:https://letsencrypt.org/zh-cn/how-it-works/
- 発行者APIドキュメント:https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.Issuer
- 証明書APIドキュメント:https://cert-manager.io/docs/reference/api-docs/#cert-manager.io/v1.Certificate