Kubernetes 환경에서 인증서 관리 자동화

NGINX | 2022년 10월 05일

유효한 SSL/TLS 인증서는 현대적인 애플리케이션 환경의 핵심 요건입니다. 하지만 애플리케이션을 배포할 때 인증서 갱신 관리는 흔히 나중에 고려됩니다. 인증서의 유효 기간은 제한되어 있으며, 대략 DigiCert 인증서의 경우 13개월에서 Let’s Encrypt 인증서의 경우 90일까지 다양합니다. 안전한 액세스를 유지하려면 이러한 인증서를 만료 전에 갱신하거나 재발급해야 합니다. 대부분의 운영 팀은 업무량이 상당하기 때문에 인증서 갱신을 간혹 놓치기도 하며, 그 결과 인증서 만료일이 임박하거나, 더 심각하게는 이미 만료된 후에야 다급히 대응하게 됩니다.

꼭 이렇게 번거로울 필요는 없습니다. 약간의 계획과 준비만으로 인증서 관리를 자동화하고 간소화할 수 있습니다. 여기서는 다음 세 가지 기술을 활용한 Kubernetes용 솔루션을 살펴보겠습니다:

이 블로그에서는 엔드포인트마다 고유한 인증서를 제공하고 이를 자동으로 갱신 및 업데이트하여 인증서 관리를 간소화하는 방법을 알아봅니다.

Kubernetes 환경의 인증서

기술적인 세부 사항을 살펴보기 전에 몇 가지 용어를 정의해야 합니다. “TLS 인증서”라는 용어는 Ingress 컨트롤러에서 HTTPS 연결을 활성화하는 데 필요한 두 가지 구성 요소를 의미합니다:

인증서
개인 키

인증서와 개인 키는 모두 Let’s Encrypt에서 발급합니다. TLS 인증서의 작동 방식에 대한 자세한 설명은 DigiCert의 게시물인 TLS/SSL 인증서의 작동 방식을 참조하세요.

Kubernetes에서 이 두 구성 요소는 Secret으로 저장됩니다. NGINX Ingress Controller 및 cert-manager와 같은 Kubernetes 워크로드는 이러한 Secret을 쓰고 읽을 수 있으며, Kubernetes 설치 환경에 대한 액세스 권한이 있는 사용자도 이를 관리할 수 있습니다.

cert-manager 소개

The cert-manager 프로젝트는 Kubernetes 및 OpenShift에서 작동하는 인증서 컨트롤러입니다. Kubernetes에 배포하면 cert-manager가 Ingress 컨트롤러에 필요한 인증서를 자동으로 발급하고, 인증서가 유효한 최신 상태로 유지되도록 합니다. 또한 인증서의 만료일을 추적하고 설정된 시간 간격에 따라 갱신을 시도합니다. 다양한 공인 및 사설 발급 기관과 연동되지만, 여기서는 Let’s Encrypt와의 통합을 살펴보겠습니다.

두 가지 챌린지 유형

Let’s Encrypt를 사용하면 모든 인증서 관리가 자동으로 처리됩니다. 이는 매우 편리하지만 한 가지 문제가 있습니다. 서비스는 해당 정규화된 도메인 이름(FQDN)의 소유자가 사용자임을 어떻게 확인할까요?

이 문제는 챌린지를 사용하여 해결합니다. 챌린지에서는 해당 도메인의 DNS 레코드에 액세스할 수 있는 사람만 응답할 수 있는 확인 요청에 답해야 합니다. 챌린지는 다음 두 가지 형태 중 하나로 진행됩니다:

HTTP-01: 인증서를 발급하려는 FQDN의 DNS 레코드가 있으면 이 챌린지에 응답할 수 있습니다. 예를 들어 서버의 IP가 www.xxx.yyy.zzz이고 FQDN이 cert.example.com인 경우, 챌린지 메커니즘은 www.xxx.yyy.zzz의 서버에 토큰을 노출하고 Let’s Encrypt 서버는 cert.example.com을 통해 해당 토큰에 접근을 시도합니다. 성공하면 챌린지를 통과하고 인증서가 발급됩니다. HTTP-01은 DNS 공급자에 직접 액세스할 필요가 없으므로 인증서를 생성하는 가장 간단한 방법입니다. 이 유형의 챌린지는 항상 포트 80(HTTP)을 통해 수행됩니다. HTTP-01 챌린지를 사용할 때 cert-manager는 Ingress 컨트롤러를 사용하여 챌린지 토큰을 제공한다는 점에 유의하세요.

DNS-01: 이 챌린지는 토큰이 포함된 DNS TXT 레코드를 생성하며, 이후 발급자가 이를 검증합니다. 토큰이 확인되면 해당 도메인의 소유권이 입증되어 그 도메인의 레코드에 대한 인증서를 발급할 수 있습니다. HTTP-01 챌린지와 달리 DNS-01 챌린지를 사용할 때는 FQDN이 서버의 IP 주소로 확인될 필요가 없으며, 실제로 존재하지 않아도 됩니다. 또한 포트 80이 차단된 경우에도 DNS-01을 사용할 수 있습니다. 이러한 편의성의 대가로 cert-manager 설치 환경에 API 토큰을 통해 DNS 인프라에 대한 접근 권한을 제공해야 합니다.

인그레스 컨트롤러

An Ingress 컨트롤러는 클러스터 외부의 트래픽을 가져와 내부 Pod(하나 이상의 컨테이너로 구성된 그룹)로 부하 분산하고 송신 트래픽을 관리하는 Kubernetes용 특수 서비스입니다. 또한 Ingress 컨트롤러는 Kubernetes API를 통해 제어되며, Pod가 추가되거나 제거되거나 장애가 발생하면 부하 분산 구성을 모니터링하고 업데이트합니다.

Ingress 컨트롤러에 대해 자세히 알아보려면 다음 블로그를 읽어보세요:

아래 예제에서는 F5 NGINX에서 개발하고 유지 관리하는 NGINX Ingress Controller를 사용합니다.

인증서 관리 예시

이 예제에서는 테스트에 사용할 수 있는 정상 작동 중인 Kubernetes 설치 환경이 있고, 해당 환경에서 외부 IP 주소(Kubernetes LoadBalancer 객체)를 할당할 수 있다고 가정합니다. 또한 HTTP-01 챌린지를 사용하는 경우 포트 80과 포트 443 모두에서, DNS-01 챌린지를 사용하는 경우 포트 443에서만 트래픽을 수신할 수 있다고 가정합니다. 이 예제는 Mac OS X를 기준으로 설명하지만 Linux 또는 WSL에서도 사용할 수 있습니다.

또한 A 레코드를 조정할 수 있는 DNS 공급자와 FQDN이 필요합니다. HTTP-01 챌린지를 사용하는 경우 A 레코드를 추가할 수 있거나 다른 사람이 대신 추가해 줄 수 있으면 됩니다. DNS-01 챌린지를 사용하는 경우 지원되는 DNS 공급자 또는 지원되는 웹후크 공급자에 대한 API 액세스 권한이 필요합니다.

NGINX Ingress Controller 배포

가장 쉬운 방법은 Helm을 통해 배포하는 것입니다. 이 배포 방식을 사용하면 Kubernetes Ingress와 NGINX Virtual Server CRD를 모두 사용할 수 있습니다.

NGINX 리포지토리를 추가합니다.

$ helm repo add nginx-stable https://helm.nginx.com/stable  "nginx-stable" has been added to your repositories

리포지토리를 업데이트합니다.

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  Update Complete. ⎈Happy Helming!⎈

Ingress 컨트롤러를 배포합니다.

$ helm install nginx-kic nginx-stable/nginx-ingress \  --namespace nginx-ingress  --set controller.enableCustomResources=true \ 
  --create-namespace  --set controller.enableCertManager=true 
  NAME: nginx-kic
  LAST DEPLOYED: Thu Sep  1 15:58:15 2022
  NAMESPACE: nginx-ingress
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None
  NOTES:
  The NGINX Ingress Controller has been installed.

배포를 확인하고 Ingress 컨트롤러의 송신 IP 주소를 가져옵니다. 유효한 IP 주소가 없으면 계속 진행할 수 없습니다.

$ kubectl get deployments --namespace nginx-ingress  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  nginx-kic-nginx-ingress   1/1     1            1           23s
  $ kubectl get services --namespace nginx-ingress
  NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
  nginx-kic-nginx-ingress   LoadBalancer   10.128.60.190   www.xxx.yyy.zzz   80:31526/TCP,443:32058/TCP   30s

DNS A 레코드 추가

여기서의 절차는 사용 중인 DNS 제공업체에 따라 달라집니다. 이 DNS 이름은 Let’s Encrypt 서버에서 확인할 수 있어야 하므로, 정상적으로 작동하려면 레코드가 전파될 때까지 기다려야 할 수 있습니다. 자세한 내용은 SiteGround의 다음 문서를 참조하세요. DNS 전파란 무엇이며 왜 이렇게 오래 걸리나요?

선택한 FQDN을 확인할 수 있게 되면 다음 단계로 진행할 준비가 된 것입니다.

$ host cert.example.com  cert.example.com has address www.xxx.yyy.zzz

cert-manager 배포

다음 단계는 최신 버전의 cert-manager를 배포하는 것입니다. 이번에도 Helm을 사용하여 배포하겠습니다.

Helm 리포지토리를 추가합니다.

$ helm repo add jetstack https://charts.jetstack.io  "jetstack" has been added to your repositories

리포지토리를 업데이트합니다.

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  ...Successfully got an update from the "jetstack" chart repository
  Update Complete. ⎈Happy Helming!⎈

cert-manager를 배포합니다.

$ helm install cert-manager jetstack/cert-manager \  --namespace cert-manager --create-namespace \
  --version v1.9.1  --set installCRDs=true 
  NAME: cert-manager
  LAST DEPLOYED: Thu Sep  1 16:01:52 2022 
  NAMESPACE: cert-manager
  STATUS: deployed
  REVISION: 1 
  TEST SUITE: None
  NOTES:
  cert-manager v1.9.1 has been deployed successfully!
  In order to begin issuing certificates, you will need to set up a ClusterIssuer
  or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).
  More information on the different types of issuers and how to configure them
  can be found in our documentation:
  https://cert-manager.io/docs/configuration/ For information on how to configure cert-manager to automatically provision
  Certificates for Ingress resources, take a look at the `ingress-shim`
  documentation:
  https://cert-manager.io/docs/usage/ingress/

배포를 검증합니다.

$ kubectl get deployments --namespace cert-manager  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  cert-manager              1/1     1            1           4m30s
  cert-manager-cainjector   1/1     1            1           4m30s
  cert-manager-webhook      1/1     1            1           4m30s

NGINX Cafe 예제 배포

백엔드 배포와 서비스를 구성하기 위해 NGINX Cafe 예제를 사용하겠습니다. 이 예제는 NGINX에서 제공하는 문서에서 흔히 사용됩니다. 여기서는 Ingress를 배포하지 않습니다.

NGINX Ingress GitHub 프로젝트를 복제합니다.

$ git clone https://github.com/nginxinc/kubernetes-ingress.git  Cloning into 'kubernetes-ingress'...
  remote: Enumerating objects: 44979, done.
  remote: Counting objects: 100% (172/172), done.
  remote: Compressing objects: 100% (108/108), done.
  remote: Total 44979 (delta 87), reused 120 (delta 63), pack-reused 44807
  Receiving objects: 100% (44979/44979), 60.27 MiB | 27.33 MiB/s, done.
  Resolving deltas: 100% (26508/26508), done.

examples 디렉터리로 이동합니다. 이 디렉터리에는 Ingress 컨트롤러의 다양한 구성을 보여 주는 여러 예제가 포함되어 있습니다. 여기서는 complete-example 디렉터리에 있는 예제를 사용합니다.

$ cd ./kubernetes-ingress/examples/ingress-resources/complete-example

NGINX Cafe 예제를 배포합니다.

$ kubectl apply -f ./cafe.yaml
  deployment.apps/coffee created
  service/coffee-svc created
  deployment.apps/tea created
  service/tea-svc created

Validate the deployment and Services using the kubectl get 명령을 사용하여 배포와 서비스를 검증합니다. Pod가 READY로 표시되고 서비스가 running으로 표시되는지 확인합니다. 아래 예시는 확인해야 할 결과의 대표적인 예입니다. kubernetes 서비스는 NGINX Cafe 예제와 동일한 네임스페이스(default)에서 실행되는 시스템 서비스입니다.

$ kubectl get deployments,services  --namespace default  NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
  deployment.apps/coffee   2/2     2            2           69s
  deployment.apps/tea      3/3     3            3           68s
NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
  service/coffee-svc   ClusterIP   10.128.154.225   <none>        80/TCP    68s
  service/kubernetes   ClusterIP   10.128.0.1       <none>        443/TCP   29m
	service/tea-svc      ClusterIP   10.128.96.145    <none>        80/TCP    68s

ClusterIssuer 배포

cert-manager에서 ClusterIssuer를 사용하여 인증서를 발급할 수 있습니다. 이는 모든 네임스페이스에서 참조할 수 있는 클러스터 범위 객체이며, 정의된 인증서 발급 기관을 사용하는 모든 인증서 요청에 활용할 수 있습니다. 이 예시에서는 Let’s Encrypt 인증서에 대한 모든 요청을 이 ClusterIssuer가 처리할 수 있습니다.

선택한 챌린지 유형에 맞는 ClusterIssuer를 배포합니다. 이 게시물에서 다루는 범위를 벗어나지만, ClusterIssuer에서 여러 리졸버(선택기 필드에 따라 선택됨)를 지정할 수 있는 고급 구성 옵션이 있습니다.

ACME 챌린지 기본 사항

자동 인증서 관리 환경(ACME) 프로토콜은 도메인 이름의 소유권을 확인하여 Let’s Encrypt 인증서를 발급받을 수 있는지 판단하는 데 사용됩니다. 이 챌린지에는 다음 매개변수를 전달해야 합니다:

metadata.name: Kubernetes 설치 내에서 고유해야 하는 ClusterIssuer 이름입니다. 이 이름은 이후 인증서를 발급하는 예제에서 사용됩니다.
spec.acme.email: 인증서를 생성하기 위해 Let’s Encrypt에 등록하는 이메일 주소입니다. 본인의 이메일 주소를 입력해야 합니다.
spec.acme.privateKeySecretRef: 프라이빗 키를 저장하는 데 사용할 Kubernetes 시크릿의 이름입니다.
spec.acme.solvers: 이 항목은 그대로 두어야 합니다. 사용 중인 챌린지 유형(ACME에서는 이를 솔버라고 함)(HTTP-01 또는 DNS-01)과 적용할 Ingress 클래스를 지정하며, 이 경우에는 nginx입니다.

HTTP-01 사용

이 예제에서는 HTTP-01 챌린지를 사용하여 도메인 소유권을 증명하고 인증서를 발급받도록 ClusterIssuer를 설정하는 방법을 보여줍니다.

HTTP-01 챌린지를 사용하는 ClusterIssuer를 생성합니다.

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
      - http01:
         ingress:
           class: nginx
  EOF
  clusterissuer.cert-manager.io/prod-issuer created

ClusterIssuer를 검증합니다(준비됨으로 표시되어야 함).

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    34s

DNS-01 사용

이 예제에서는 DNS-01 챌린지를 사용하여 도메인 소유권을 인증하도록 ClusterIssuer를 설정하는 방법을 보여 줍니다. DNS 제공업체에 따라 토큰을 저장하기 위해 Kubernetes Secret을 사용해야 할 수 있습니다. 이 예제에서는 Cloudflare를 사용합니다. 네임스페이스 사용에 유의하세요. cert-manager 네임스페이스에 배포된 cert-manager 애플리케이션은 해당 Secret에 액세스할 수 있어야 합니다.

이 예시를 진행하려면 계정에서 생성할 수 있는 Cloudflare API 토큰이 필요합니다. 생성한 토큰은 아래의 <API Token> 줄에 입력해야 합니다. Cloudflare를 사용하지 않는 경우에는 사용 중인 공급자의 문서를 참조하세요.

API 토큰을 위한 Secret을 생성합니다.

$ cat << EOF | kubectl apply -f   apiVersion: v1
  kind: Secret
  metadata:
    name: cloudflare-api-token-secret
    namespace: cert-manager
  type: Opaque
  stringData:
    api-token: <API Token> 
  EOF

DNS-01 챌린지를 사용하여 발급자를 생성합니다.

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
        - dns01:
            cloudflare:
              apiTokenSecretRef:
                name: cloudflare-api-token-secret
                key: api-token
  EOF

발급자를 검증합니다(준비됨으로 표시되어야 함).

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    31m

Ingress 배포

이제 지금까지 준비해 온 단계인 애플리케이션용 Ingress 리소스를 배포할 차례입니다. 이를 통해 트래픽이 앞서 배포한 NGINX Cafe 애플리케이션으로 라우팅됩니다.

Kubernetes Ingress 사용하기

표준 Kubernetes Ingress 리소스를 사용하는 경우, 다음 배포 YAML을 사용하여 Ingress를 구성하고 인증서를 요청합니다.

apiVersion: networking.k8s.io/v1   kind: Ingress 
  metadata: 
    name: cafe-ingress 
    annotations: 
      cert-manager.io/cluster-issuer: prod-issuer 
      acme.cert-manager.io/http01-edit-in-place: "true" 
  spec: 
    ingressClassName: nginx 
    tls: 
    - hosts: 
      - cert.example.com 
      secretName: cafe-secret 
    rules: 
    - host: cert.example.com 
      http: 
        paths: 
        - path: /tea 
          pathType: Prefix 
          backend: 
            service: 
              name: tea-svc 
              port: 
                number: 80 
        - path: /coffee 
          pathType: Prefix 
          backend: 
            service: 
              name: coffee-svc 
              port: 
number: 80

매니페스트의 몇 가지 핵심 부분을 살펴보겠습니다:

호출되는 API는 표준 Kubernetes Ingress입니다.
이 구성의 핵심 부분은 metadata.annotations 아래에 있으며, 여기서 acme.cert-manager.io/http01-edit-in-place를 “true”로 설정합니다. 이 값은 필수이며 챌린지가 제공되는 방식을 조정합니다. 자세한 내용은 지원되는 어노테이션 문서를 참조하세요. 또한 마스터/미니언 설정을 사용하여 처리할 수도 있습니다.
The spec.ingressClassName은 설치를 완료했으며 앞으로 사용할 NGINX Ingress 컨트롤러를 가리킵니다.
The spec.tls.secret Kubernetes Secret 리소스는 Let’s Encrypt에서 인증서를 발급할 때 반환되는 인증서 키를 저장합니다.
호스트 이름인 cert.example.com은(는) spec.tls.hosts 및 spec.rules.host에 지정됩니다. 이는 ClusterIssuer가 인증서를 발급한 호스트 이름입니다.
The spec.rules.http 섹션은 경로와 해당 경로의 요청을 처리할 백엔드 서비스를 정의합니다. 예를 들어, /tea로 향하는 트래픽은 tea-svc의 포트 80으로 전달됩니다.

설치 환경에 맞게 위 매니페스트를 수정합니다. 최소한 spec.rules.host 및 spec.tls.hosts 값을 변경해야 하지만, 구성의 모든 매개변수를 검토해야 합니다.
매니페스트를 적용합니다.

$  kubectl apply -f ./cafe-virtual-server.yaml  virtualserver.k8s.nginx.org/cafe created

인증서가 발급될 때까지 기다립니다. READY 필드의 값이 “True”인지 확인합니다.

$ kubectl get certificates  NAME                                      READY   SECRET        AGE
  certificate.cert-manager.io/cafe-secret   True    cafe-secret   37m

NGINX Virtual Server / Virtual Routes 사용

NGINX CRD를 사용하는 경우 다음 배포 YAML을 사용하여 Ingress를 구성해야 합니다.

  apiVersion: k8s.nginx.org/v1 
  kind: VirtualServer 
  metadata: 
    name: cafe 
  spec: 
    host: cert.example.com 
    tls: 
      secret: cafe-secret 
      cert-manager: 
        cluster-issuer: prod-issuer 
    upstreams: 
      - name: tea 
        service: tea-svc 
        port: 80 
      - name: coffee 
        service: coffee-svc 
        port: 80 
    routes: 
      - path: /tea 
        action: 
          pass: tea 
      - path: /coffee 
        action: 
          pass: coffee

다시 한번 매니페스트의 몇 가지 핵심 부분을 살펴보겠습니다:

호출되는 API는 VirtualServer 리소스를 위한 NGINX 전용 k8s.nginx.org/v1입니다.
The spec.tls.secret Kubernetes Secret 리소스에는 Let’s Encrypt에서 인증서를 발급할 때 반환되는 인증서 키가 저장됩니다.
호스트 이름인 cert.example.com은(는) spec.host에 지정됩니다. 이 호스트 이름에 대해 ClusterIssuer가 인증서를 발급했습니다.
The spec.upstreams 값은 포트를 포함한 백엔드 서비스를 가리킵니다.
The spec.routes는 경로와 해당 경로에 요청이 들어왔을 때 수행할 작업을 모두 정의합니다.

설치 환경에 맞게 위 매니페스트를 수정합니다. 최소한 spec.host 값을 변경해야 하며, 구성의 모든 매개변수를 검토해야 합니다.
매니페스트를 적용합니다.

$  kubectl apply -f ./cafe-virtual-server.yaml  virtualserver.k8s.nginx.org/cafe created

인증서가 발급될 때까지 기다립니다. 상태가 Valid로 표시되어야 합니다.

$ kubectl get VirtualServers  NAME   STATE   HOST                    IP             PORTS      AGE
  cafe   Valid   cert.example.com   www.xxx.yyy.zzz   [80,443]   51m

인증서 보기

Kubernetes API를 통해 인증서를 확인할 수 있습니다. 인증서의 크기와 연결된 비공개 키를 비롯한 세부 정보가 표시됩니다.

$ kubectl describe secret cafe-secret  Name:         cafe-secret
  Namespace:    default
  Labels:       <none>
  Annotations:  cert-manager.io/alt-names: cert.example.com
                cert-manager.io/certificate-name: cafe-secret
                cert-manager.io/common-name: cert.example.com
                cert-manager.io/ip-sans:
                cert-manager.io/issuer-group:
                cert-manager.io/issuer-kind: ClusterIssuer
                cert-manager.io/issuer-name: prod-issuer
                cert-manager.io/uri-sans:Type:  kubernetes.io/tlsData
  ====
  tls.crt:  5607 bytes
  tls.key:  1675 bytes

실제 인증서와 키를 확인하려면 다음 명령을 실행하면 됩니다. (참고: 이는 Kubernetes Secret의 취약점을 보여 주기도 합니다. 즉, 필요한 접근 권한이 있는 사람이라면 누구나 이를 읽을 수 있습니다.)

$ kubectl get secret cafe-secret -o yaml

Ingress 테스트

인증서를 테스트합니다. 여기서는 원하는 방법을 사용할 수 있습니다. 아래 예에서는 cURL을 사용합니다. 성공하면 앞서 표시된 것과 유사한 블록이 나타나며, 여기에는 서버 이름, 서버의 내부 주소, 날짜, 선택한 URI(경로)(coffee 또는 tea), 요청 ID가 포함됩니다. 실패하면 HTTP 오류 코드가 표시되며, 대부분 400 또는 301입니다.

$ curl https://cert.example.com/tea
  Server address: 10.2.0.6:8080
  Server name: tea-5c457db9-l4pvq
  Date: 02/Sep/2022:15:21:06 +0000
  URI: /tea
  Request ID: d736db9f696423c6212ffc70cd7ebecf
  $ curl https://cert.example.com/coffee
  Server address: 10.2.2.6:8080
  Server name: coffee-7c86d7d67c-kjddk
  Date: 02/Sep/2022:15:21:10 +0000
  URI: /coffee
Request ID: 4ea3aa1c87d2f1d80a706dde91f31d54

인증서 갱신

처음에 이 접근 방식을 사용하면 인증서 갱신을 관리할 필요가 없어진다고 말씀드렸습니다. 하지만 아직 그 방법을 설명하지 않았습니다. 왜일까요? 인증서 갱신은 cert-manager에 기본으로 내장된 핵심 기능이기 때문입니다. 이 자동화된 프로세스에서 cert-manager는 인증서가 없거나, 만료되었거나, 만료일까지 15일 이내로 남았거나, 사용자가 CLI를 통해 새 인증서를 요청한 경우 새 인증서를 자동으로 요청합니다. 이보다 더 간단할 수는 없습니다.

자주 묻는 질문

NGINX Plus는 어떤가요?

NGINX Plus 구독자인 경우 유일한 차이점은 NGINX Ingress Controller 설치와 관련된 부분입니다. 위에 제시된 Helm 명령을 수정하는 방법은 NGINX 문서의 Helm 설치 섹션을 참조하세요.

어떤 챌린지 유형을 사용해야 하나요?

이는 주로 사용 사례에 따라 달라집니다.

HTTP-01 챌린지 방식을 사용하려면 포트 80이 인터넷에 개방되어 있어야 하며, DNS A 레코드가 Ingress 컨트롤러의 IP 주소로 올바르게 구성되어 있어야 합니다. 이 방식에서는 A 레코드를 생성하는 것 외에는 DNS 제공업체에 접근할 필요가 없습니다.

DNS-01 챌린지 방식은 포트 80을 인터넷에 노출할 수 없는 경우에 사용할 수 있으며, cert-manager가 DNS 공급자에 대한 아웃바운드 액세스 권한만 있으면 됩니다. 하지만 이 방식을 사용하려면 DNS 공급자의 API에 액세스할 수 있어야 하며, 필요한 액세스 수준은 공급자마다 다릅니다.

문제를 해결하려면 어떻게 해야 하나요?

Kubernetes는 매우 복잡하기 때문에 특정 문제에 맞는 문제 해결 정보를 제공하기가 어렵습니다. 문제가 발생하면 NGINX 커뮤니티 Slack에서 문의해 주세요(NGINX Plus 구독자는 기존 지원 옵션을 이용할 수 있습니다).

지금 시작하세요

무료 30일 평가판을 신청하여 NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller를 시작하고, 항상 무료로 제공되는 NGINX Service Mesh를 다운로드하세요.

작성자 소개

Jason Schmidt

Jason Schmidt의 다른 블로그 게시물