기본 지식

cert-manager란?

kubernetes 클러스터에서 SSL/TLS 인증서를 간단하게 처리하는 도구입니다.
인증서의 취득, 갱신, 사용이 간단해졌다.
공식 문서
https://cert-manager.io/docs/

이 글의 내용

이 글에서는 cert-Manager를 사용하면서 최소한 통제해야 할'증명서 발행·활용 프로세스'와'등장인물'만 간단히 정리했다.
증명서 주변에서는 사고가 나면 귀찮아서 만지고 싶지 않을 수도 있지만 기초 지식을 먼저 알고 싶은 것이 최초의 발판이다.
cert-manager v1.이어서 6.1의 이야기를 하겠습니다.
또한 Let's Encerypt를 Issuer의 프로세스로 설명하기 때문에 다른 Issuer Type에는 다른 내용이 있습니다.

인증서 발행 및 사용의 간단한 절차

우선 대략적인 절차를 하나 써라.
실제 설치 방법과 조작 등 상세한 내용은 공식 문서에 넘길 것이다.

cert-Manager를 설치합니다.

Issuer 어셈블리를 생성합니다.

Certificate 어셈블리를 생성합니다.

Issuer, Certificate 구성 요소의 설정에 따라 지정한 인증서 발행인에게 지정한 영역의 인증서를 요청합니다.

지정한 영역이 인증서 요청자의 통제하에 있는지 확인하기 위해 인증서 발행인이 실행한다チャレンジ.

チャレンジ가 완료되면 발행된 인증서와 키는 Secret 자원에 저장됩니다.

인증서와 키가 저장된 시크릿은 참조Ingress 등을 통해 인증서로 암호 통신을 할 수 있습니다.

등장인물

cert-Manager는 인증서를 취득하고 이용할 때 관련 등장인물을 소개한다.

Issuer

https://cert-manager.io/docs/concepts/issuer/

증명서 발행자(CA:Centefication Authority. 일본어는 인증국).

글자의 뜻대로 증명서를 발행한 사람이다.

cert-Manager에서 Issuer 구성 요소는 Custom Resource Definition(CRD)에 의해 정의된 자원입니다.

Issuer 구성 요소는 같은namespace에서만 발행할 수 있습니다Certificate.

여러 개의 Namespace를 뛰어넘어 발행하고 싶을 때 ClusterIssuer 구성 요소를 사용합니다.

터미널 사용자가 manfest 파일을 만들고 관리합니다.

Certificate

https://cert-manager.io/docs/concepts/certificate/

는 X.509 기반 인증서를 나타냅니다.

이것도 CRD에서 정의한 Kubbernetes의 자원이다.

X.509은 인증서의 사양입니다.

여기 기사.에 통속적이고 알기 쉽게 썼다.

터미널 사용자가 manfest 파일을 만들고 관리합니다.

ACME Orders and Challenges

https://cert-manager.io/docs/concepts/acme-orders-challenges/

ACME(Automate Certificate Management Environment)

인증서를 자동으로 관리하는 환경입니다.

Let's Encerypt는 대표적인 ACME Issuer입니다.

인증서 서명 요청을 통과하기 위해 ACME 클라이언트(즉,cert-Manager, 터미널 사용자)는 ACME Issuer에 지정된 도메인을 가지고 있음을 증명해야 합니다.

이것은 ACME 프로토콜에서 チャレンジ라고 불리는 메커니즘이다.

이것チャレンジ을 완성하기 위해cert-Manager는 다음 두 개의 CRD를 가져옵니다.

Order

Challenge

Order

チャレンジ는 실행 요청을 나타낸다.

チャレンジ의 상세한 내용은 여기.이다.

터미널 사용자가 만들지 않습니다.한번 해봤자 변하지 않을 거야.

Challenge

표시 チャレンジ.

여러 도메인을 요청한 경우 Order 하나에 대해 여러 도메인Challenge을 생성합니다.

Charllenge 수명 주기

Challenge 대기열에서 순서대로 처리합니다.

チャレンジ 완성 후Challenge 자원이 Kubernetes 그룹에서 사라집니다.

터미널 사용자가 만들지 않습니다.한번 해봤자 변하지 않을 거야.

Ingress

Kubbernetes 클러스터 내의 HTTP(S)에 액세스하는 리소스를 관리합니다.

Nginx와 같은 웹 서버로 제공되거나 GCP, AWS 등 관리 서비스의 부하 밸런서로 제공될 때도 있다.

SSL/TLS 인증서를 참조하여 SSL 말단으로 사용할 수 있습니다.

cert-Manager를 사용하여 얻은 인증서는 최종적으로 Ingress에서 참고하고 사용합니다.

터미널 사용자가 manfest 파일을 만들고 관리합니다.

Ingresscert-Manager가 CRD로 정의하는 리소스가 아닙니다.

등장인물별 manfest 파일 샘플

위에서 말한 바와 같이 다음 세 가지 자원은 사용자가 manfest 파일을 제작하고 관리해야 한다.

Issuer

Certificate

Ingress

다음은 이 세 자원에 대한 manfest 파일의 견본과 관계를 보여 줍니다.

문서 견본

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: YOUR_ISSUER_NAME
spec:
  acme:
    email: "hoge@example.com"
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: lets-encrypt
    solvers:
    - dns01:
        cloudDNS:
          project: example-com
          serviceAccountSecretRef:
            name: prod-clouddns-svc-acct-secret
            key: service-account.json

Issuer의 manfest 중 가장 중요한 것은 metadata.name와spec以下이다.metadata.name가 바로 이 자원의 명칭이다.중요한 것은 다른 자원에서 이 자원을 인용하는 것이다.spec以下 타입에 따라 다릅니다.이번에는 Let's Encerypt를 사용하는 전제조건이기 때문에Issuer.
이 manfest는 Staging 환경의 Let's Encerypt 서버에 대한 실행spec.acme입니다. GCP의 클라우드 DNS를 사용하세요. DNS01チャレンジ라는 GCP 프로젝트의 클라우드 DNS를 사용하기 위해example-com이 시크릿 자원에 서비스 계정의 신용도를 놓았습니다.
다른 IssuerType 또는 ACME를 사용하여 다른 설정을 선택할 때는 공식 문서를 참조하십시오.
https://cert-manager.io/docs/configuration/

문서 견본

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: YOUR_CERTIFICATE_NAME
spec:
  secretName: YOUR_SECRET_NAME
  dnsNames:
  - example.com
  issuerRef:
    name: YOUR_ISSUER_NAME
    kind: Issuer

prod-clouddns-svc-acct-secret 구성 요소의 manfest 파일에 Certificate,secretName,dnsNames의 필드가 존재합니다.issuerRef에서 지정한 dnsNames에서 지정한 issuerRef에서 Issuer에서 지정한 영역의 인증서를 받습니다.secretName Kubernetes의 Secret 자원 이름을 지정합니다.이 Secret은 실제 키와 인증서를 저장합니다.
manfest 파일을 설정하면 example.com 인증서는 YOUR_ISSUER_NAME 라는 Issueer 에서 가져오고 인증서와 키는 YOUR_SECRET_NAME 라는 Secret 자원에 저장됩니다.
실제 시크릿에 저장된 예는 다음과 같습니다.

$ kubectl get secret ${YOUR_SECRET_NAME}

apiVersion: v1
kind: Secret
data:
  tls.crt: LS0tLaa.....
  tls.key: LS0tLOU....
  creationTimestamp: "2022-00-00T00:00:00Z"
  labels:
    certmanager.k8s.io/certificate-name: YOUR_SECRET_NAME
  name: YOUR_SECRET_NAME
  namespace: YOUR_NAMESPACE_NAME
...
...

인증서data.tls.crt는 인증서 값을 포함하고 data.tls.key는 키 값을 포함한다.
이 값을 사용하여 암호 통신을 실현합니다.
참고로 실제 인증서의 값은 Secret에만 존재합니다.
헷갈리기 쉽습니다. Certificate 자원에 인증서 값이 존재하지 않습니다.
대신 인증서 실효, 예정일 갱신 등의 정보를 포함한다.

$ kubectl get Certificate ${YOUR_CERTIFICATE_NAME}

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  creationTimestamp: "2022-01-13T12:19:50Z"
  generation: 1
  name: YOUR_CERTIFICATE_NAME
  namespace: YOUR_NAMESPACE_NAME
spec:
  commonName: example.com
  dnsNames:
  - example.com
  issuerRef:
    kind: Issuer
    name: YOUR_ISSUER_NAME
  secretName: YOUR_SECRET_NAME
status:
  conditions:
  - lastTransitionTime: "2022-01-13T12:19:50Z" # 2022/1/13に作成
    message: Certificate is up to date and has not expired
    observedGeneration: 1
    reason: Ready
    status: "True"
    type: Ready
  notAfter: "2022-04-13T11:21:25Z" # 90日後の2022/4/13に失効
  notBefore: "2022-01-13T11:21:26Z"
  renewalTime: "2022-03-14T11:21:25Z" # 60日後の2022/3/14に更新予定
  revision: 1

문서 견본

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/issuer: YOUR_ISSUER_NAME
  name: YOUR_INGRESS_NAME
  namespace: YOUR_INGRESS_NAME
spec:
  rules:
  - host: example.com
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: YOUR_SERVICE_NAME
            port:
              number: 80
  tls:
  - hosts:
    - example.com
    secretName: YOUR_SECRET_NAME

tls.hosts[0].secretName에 인증서와 키를 가진 시크릿의 이름을 입력함으로써 Ingress는 인증서를 참조하여 암호 통신을 실현한다.
즉 Certificate의manfest 내spec.secretName값과 같으면 OK라는 것이다.

총결산

간단하게 말하면 manfest 파일의 샘플을 포함하여cert-관리자가 인증서를 취득하고 사용하는 절차를 소개했다.
cert-Manager의 공식 문서가 비교적 충실해서 나는 배울 만하다고 생각한다.
관심 있는 사람이 자세히 읽어보면 재미있을 거예요.