cert-manager について簡潔にまとめておきますね
この記事はなむゆの個人ブログにも投稿しています。
https://namyusql.hatenablog.com/entry/2024-05-16-cert-manager-simple-doc
はじめに
最近触った環境で cert-manager というソフトウェアを使用していて、その概要について把握するのにまあまあ時間がかかったため、あとで忘れたときの備忘録として、そして同様にソフトウェアについて把握したい方向けに簡潔にまとめておきます。
cert-manager とは
Kubernetes や OpenShift 上で動作する TLS 証明書の管理ソフトウェアです。
Kubernetes 上で Pod が常駐し、証明書が期限切れになる前に定期的に証明書の更新を自動的に行ってくれます。
作成した証明書は Kubernetes の Secret として自動生成されます。
Helm またはマニフェストで直接インストール可能です。
apiVersion: v1
kind: Secret
metadata:
name: my-cert-tls
type: kubernetes.io/tls
data:
ca.crt: <PEM CA certificate>
tls.key: <PEM private key>
tls.crt: <PEM signed certificate chain>
tls-combined.pem: <PEM private key + "\n" + PEM signed certificate chain>
key.der: <DER binary format of private key>
インストール方法
※前提条件として Helm のインストールが必要ですが未インストールであれば別途インストールしてください
マニフェストでインストールする
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml
これで、cert-manager ネームスペースに cert-manager がインストールされます
Helm でインストールする
helm repo add jetstack https://charts.jetstack.io --force-update
helm repo update
helm install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--version v1.14.5 \
--set installCRDs=true
インストールされるカスタムリソース例
cert-manager をインストールすると、cert-manager で使用するいくつかのカスタムリソースが Kubernetes 上にインストールされます。
cert-manager を使用しているクラスターには以下のリソースが存在するため、探してみてください。
インストールされるものの中で代表的なものは以下です。
Issuer
証明書を取得する認証局の設定を行います。
取得する元の認証局によって設定値が異なります。
パターンによる実装例はこちらから
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: ca-issuer
namespace: mesh-system
spec:
ca:
secretName: ca-key-pair
ClusterIssuer
Issuer を全ての Namespace で使いまわす場合に使用します。
設定値は Issuer とほぼ同じです。Namespace の指定がないのが大きな差異です。
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory
email: $EMAIL_ADDRESS
privateKeySecretRef:
name: letsencrypt-staging
solvers:
- dns01:
azureDNS:
hostedZoneName: $AZURE_ZONE_NAME
resourceGroupName: $AZURE_RESOURCE_GROUP
subscriptionID: $AZURE_SUBSCRIPTION_ID
environment: AzurePublicCloud
managedIdentity:
clientID: $IDENTITY_CLIENT_ID
Certificate
作成する証明書の詳細設定を行うリソースです。
証明書の有効期限や期限の何時間前に更新処理を行うか、作成した証明書を保存する Secret リソースの名前、証明書の CommonName 等を設定します。
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-com
namespace: sandbox
spec:
# Secret names are always required.
secretName: example-com-tls
# secretTemplate is optional. If set, these annotations and labels will be
# copied to the Secret named example-com-tls. These labels and annotations will
# be re-reconciled if the Certificate's secretTemplate changes. secretTemplate
# is also enforced, so relevant label and annotation changes on the Secret by a
# third party will be overwriten by cert-manager to match the secretTemplate.
secretTemplate:
annotations:
my-secret-annotation-1: "foo"
my-secret-annotation-2: "bar"
labels:
my-secret-label: foo
duration: 2160h # 90d
renewBefore: 360h # 15d
subject:
organizations:
- jetstack
# The use of the common name field has been deprecated since 2000 and is
# discouraged from being used.
commonName: example.com
isCA: false
privateKey:
algorithm: RSA
encoding: PKCS1
size: 2048
usages:
- server auth
- client auth
# At least one of a DNS Name, URI, IP address or otherName is required.
dnsNames:
- example.com
- www.example.com
uris:
- spiffe://cluster.local/ns/sandbox/sa/example
ipAddresses:
- 192.168.0.5
# Needs cert-manager 1.14+ and "OtherNames" feature flag
otherNames:
# Should only supply oid of ut8 valued types
- oid: 1.3.6.1.4.1.311.20.2.3 # User Principal Name "OID"
utf8Value: upn@example.local
# Issuer references are always required.
issuerRef:
name: ca-issuer
# We can reference ClusterIssuers by changing the kind here.
# The default value is Issuer (i.e. a locally namespaced Issuer)
kind: Issuer
# This is optional since cert-manager will default to this value however
# if you are using an external issuer, change this to that issuer group.
group: cert-manager.io
# keystores allows adding additional output formats. This is an example for reference only.
keystores:
pkcs12:
create: true
passwordSecretRef:
name: example-com-tls-keystore
key: password
profile: Modern2023
何か問題が起きたときは
証明書発行に何か問題が起きた場合は、まず cert-manager の Pod のログを確認することをお勧めします。
デフォルトでは cert-manager ネームスペースに証明書更新を実行する Pod がいるはずなので、
kubectl logs
コマンドで Pod のログを確認してください。また、cert-manager は起動時の設定次第では Prometheus 用フォーマットでメトリクスを出力できるので、そのメトリクスを監視することで証明書の更新失敗を検知できそうです。
具体的にどんな値が取得できるかは未検証&ドキュメントが見つかりません・・・
おわりに
以前作業を行った環境で、名前だけは聞いていた cert-manager について実際に操作する段階でいろいろと調べる羽目になったため、同様に調べるときに欲しそうな情報だけまとめておきました。
同様の場面に遭遇した誰かの役に立つと幸いです。