cert-manager를 이용한 ACME 무료인증

cert-manager란?

Kubernetes내부 HTTPS통신 인증서를 생성하기 위해 사용합니다.

Cluster내부에서 사용할수 있는 자체서명의 self-signed issuer 를 통해서 서명 할 수 있지만,

외부 무료  Issuer(ex letsencrypt)를 통해서 인증처리를 테스트하려고 합니다.

기본적으로 cert-manager는 인증서가 유효 & 최신상태인지 확인하여 항상 만료되기전 설정된 시간에 인증서 갱신을 시도합니다. (3개월갱신)

 

아래는 대표적인 cert-manager 그림

---

테스트 준비 환경

Kubernetes를 사용할수 있는 환경 준비

ACME 프로토콜 인증을 위한 도메인 세팅 - 여기서는 route53을 이용합니다.

cert-manager를 설치합니다.

---

설치

cert-manager 설치

$ kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.6.1/cert-manager.yaml

---

 

Issuer or ClusterIssuer  설명

Issuer(single namespace), ClusterIssuers(multi namepsace)

특정 namespace만 지원하길 원한다면 Issuer를 사용한다.

kubernetes에서 cluster를 첨부한 키워드는 전체 cluster에 사용가능하다는 의미이다.

Issuers와 ClusterIssuers는 kubernetes 리소스입니다.

아래와 같이 ClusterIssuer 설치합니다.

---

Issuer 등록

참조링크) https://cert-manager.io/docs/configuration/acme/

Issuer를 구성하는 spec 종류에 따른 사용방법 

 

1) selfSigned 방법 - cluster내부 https통신을 위해서 보통 사용

kubeclt apply -f 아래 파일 선택 

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-issuer
  namespace: sandbox
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-cluster-issuer
spec:
  selfSigned: {}

2) acme 방법

아래 두가지 Challenge 유효성검사 가능합니다. 

- DNS01 or HTTP01

 

HTTP01를 이용한 유효성 검사

kubeclt apply -f 아래 파일 선택 

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email: user@example.com
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource that will be used to store the account's private key.
      name: example-issuer-account-key
    # Add a single challenge solver, HTTP01 using nginx
    solvers:
    - http01:
        ingress:
          class: nginx

 

실제 위의 http01은 제대로 테스트가 안되서 아래와 같이 dns01로 route53설정하여 세팅하여 정상 동작이 가능했습니다. 

정확한 이유는 좀더 확인이 필요하여 테스트를 위해서 dns01로 우선 세팅하여 확인완료하였습니다. 

 

DNS01을 이용한 유효성 검사 (Recommend)

 

prod-route53-credentials-secret 이름의 secret생성

issue생성에서 ACME방식의 DNS01을 사용하기 위해서 secret 키 생성합니다.

kubectl --namespace cert-manager create secret generic prod-route53-credentials-secret --from-literal="secret-access-key=aws 시크릿키"

kubeclt apply -f 아래 파일 선택 

#prod

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: walter@gmail.com #change your email
    privateKeySecretRef:
      name: letsencrypt-prod # <------ 원하는 이름
    solvers:
    - dns01:
        route53:
          region: ap-northeast-2
          accessKeyID: xxxxxx # <------ 수정필요
          secretAccessKeySecretRef:
            name: prod-route53-credentials-secret # <------ 위에서 생성한 키이름
            key: secret-access-key # <------ 위에서 생성한 키이름
---



#staging

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: walter@gmail.com #change your email
    privateKeySecretRef:
      name: letsencrypt-staging # <------ 원하는 이름
    solvers:
    - dns01:
        route53:
          region: ap-northeast-2
          accessKeyID: xxxxx # <------ 수정필요
          secretAccessKeySecretRef:
            name: prod-route53-credentials-secret # <------ 위에서 생성한 키이름
            key: secret-access-key # <------ 위에서 생성한 키이름

---

Certificate

인증서 리소스를 생성 요청합니다. 

아래 Certificate파일에서 secreName은 nginx-tls이며 요청이 완료되면 secrets에 생성완료 됩니다. 

요청중일경우는 nginx-난수값의 secrets이 준비중으로 설정됩니다. 

 

kubectl apply -f cert.yaml

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: nginx
  namespace: default # istio 설치경로
spec:
  secretName: nginx-tls
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer
  commonName: test.walter.kr
  dnsNames:
  - test.walter.kr

---

Certificate 수명주기

실행시 실제 재대로 인증서 요청이 제대로 동작하는지 체크해보자

위의 certificate요청시 아래와 같은 프로세스로 진행한다.

전체 완료까지 프로세스입니다. 대략 1분여정도 시간이 소여됩니다. 

 

인증서 발생 순서

1. certificate

challenge까지 완료후 상태값 True로 세팅됨

2. certificaterequest

인승서 요청 실행시 진행

3. order

certificaterequest가 완료되면 order진행

4. challenge

order가 진행후 실제 유효성검사 체크 & 완료가 되면 certificate는 True가 되면  secret이 생성된다.

 

1) 각 단계별 상태값을 체크한다. 

kubectl get certificate 
NAME                         READY   SECRET                           AGE
nginx                        True    nginx-tls                        16h

# certificate 요청 체크 아래와 같이 하나씩 체크해본다. 
kubectl get certificate
kubectl get certificaterequest
kubectl get order
kubectl get challenge

 

certificate 수명주기

---

레퍼런스

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