단일 Kubbernetes 클러스터에서 여러 개의 단일 임차인 인증서 처리

배경.
어느 곳에서는 웹 서비스 공개를 위해 Azure Kubernetes Service를 사용하는 엔지니어가 있었다.
어느 날 그는 이런 일을 생각했다.
(-"-"-) "지금 개발 중인 기능 서버의 부하가 상당히 큽니다."
(-"-"-) "집중적으로 사용하면 다른 사용자에게 영향을 줄 수 있습니다..."
(-"-""-)""하지만 사용자에 따라 비즈니스에 영향을 미치는 것은 허용되지 않습니다..."""
(・・)!"그래, 우리 1인 세입자로 구성하자."
그래서 그는 고성능을 요구하는 사용자를 대상으로 개별적인 집단 구성을 정의하고 다른namespace로 각각 운영하는 것을 고려했다.또한 각 사용자를 대상으로 하는 전용 하위 구역이 차단되고 Azure DNS를 사용하여 각 구역에 분배하여 다른 집단을 이용한다.
엉망진창으로 그림을 만들면 이런 느낌이야.

메시지
그렇다면 평소 HTTPS가 당연한 시대가 됐고, 그의 웹 서비스도 HTTPS를 통해 서비스를 공개했다.도메인 이름이 증가하면 당연히 그 서버 인증서가 필요합니다.
증명서도 돈으로 살 수 있고, 산 증명서는 쿠버넷의 시크릿을 통해 각 팟에 상대적으로 배포할 수 있다.그러나 그는 인색하고 게으른 엔지니어로 증서를 사거나 증서가 만료될 때마다 시크릿을 갱신하는 데 시간을 들이고 싶지 않았다.
공짜 증명서를 말하자면 Let's Encrypt의 출전 시간이다.다행히 Let's Encerypt에서 인증서를 받기 위한 Kubernetes adion이 이 세상에 있고, Azure도 이를 이용한 공식 문서가 있다.
jetstack/cert-manager
Azure Kubernetes Service(AKS)를 통해 HTTPS 입구 컨트롤러 만들기
벽 1: Let's Encerypt의 속도 제한
Let's Encerypt에 관해서 그는 완전히 문외한이지만 인터넷의 견본을 참고하여 증서를 얻기 쉽다.
issuer.yml

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-key
    http01: {}

certificate.yml

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-certificate
spec:
  secretName: certs-example
  issuerRef:
    kind: Issuer
    name: letsencrypt
  commonName: "a.example.com"
  dnsNames:
    - "a.example.com"

이 한 걸음에 a.example.com증서를 받고 득의양양하게 각 명명 공간에서 같은 대상을 설계했다.이것은 매우 순조롭게 진행되었다.
하지만 그 가치를 확신하는 순간 어떤 기사가 그를 사로잡았다.
속도 제한 - Let's Encerypt-
그 보도는 이렇다.
기본 속도 제한은 등록 도메인당 인증서 수(일주일에 최대 50개)입니다.일반적으로, 등록 영역은 도메인 등록기에서 구매한 영역의 일부분이다.예: www.example.com의 경우 등록역은 example입니다.저는com입니다.new.blog.example.co.upk의 경우 등록역은 example입니다.co.uk이 되다.
이는 앞으로 사용자가 지속적으로 증가할 때 인증서의 요구는 이름 공간의 수량에서만 발생하고 속도 제한에 영향을 받을 수 있음을 의미한다.
그는 곧 죽을 것이다.
해결책
사용자 수가 증가함에 따라 대량의 도메인 이름이 필요하다고는 하지만 결국 example.com의 하위 도메인은 증가할 뿐이다.
그렇다면 어댑터 증명서*.example.com를 사용할 수 있다면 증명서를 하나로 정리할 수 있을 것이다.
잠시 조사해 보니 Let's Encerypt에서 와일드카드 인증서를 지원합니다.
잘 됐다!
벽의 2: 와일드카드 인증서 획득 제한
우리는 즉시 취득할 증서를 어댑터 형식으로 만들기로 결정했다.
certificate.yml

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-certificate
spec:
  secretName: certs-example
  issuerRef:
    kind: Issuer
    name: letsencrypt
  commonName: "*.example.com"
  dnsNames:
    - "*.example.com"

결국 지금까지 무난히 따낸 증서는 수수께끼 같은 오류로 움직이지 못했다.
그는 또 죽을 것이다.
해결책
Let's Encerypt에서 와일드카드 인증서를 얻으려면 보다 안전한 도전 방식을 사용해야 할 것 같습니다.
그는 가장 기본적인HTTP-01을 사용했지만 도전을 통해 더 믿음직스럽게DNS-01 해결했다.
cert-Manager는 Azure DNSDNS-01를 사용해 도전하는 방법을 준비해 왔기 때문에 설정해 보기로 했다.
issuer.yml

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-key
    solvers:
      - dns01:
          azureDNS:
            environment: AzurePublicCloud
            subscriptionID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
            resourceGroupName: hogehoge
            hostedZoneName: example.com
            tenantID: yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
            clientID: zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzzzzzz
            clientSecretSecretRef:
              name: azuredns
              key: azure-client-secret

이 설정이 성공적으로 실행되었고 생성된 와일드카드 인증서가 Secret으로 저장되었습니다.
잘 됐다!
벽 3: 시크릿의 역할 범위
하지만 그는 이곳에서 알아차렸다.
"시크릿은 다른 이름 공간에서 사용할 수 없나요?"
네, 어렵게 만든 인증서의 시크릿은 각 이름 공간을 공동으로 사용할 수 없다면 의미가 없습니다.그리고 지금의 Kubbernetes에는 그런 구조가 없다.
그는 세 차례 추궁했다.
해결책
그가 남긴 것은 단지 간단한 대답일 뿐이다.
"여러 이름 공간에서 반복해서 사용하지 않으면 시크릿을 복제하면 되지 않나요?"
그리고 이미 암흑가가 된 그는 난잡한 코드를 썼다.
네, 마지막으로 도와준 건 코드를 쓰는 완력이었어요.
이후 크론잡의 정기 집행으로 모든 문제가 해결됐다.
세계 평화가 도래했다.
힘냈다!
총결산
그래서 사용자마다 다양한 분야에서 다양한 용기를 제공하는 서비스 구성을 만들어 봤는데 의외로 수고하셨습니다!이렇게 되면
한차례 고심해서야 가치가 생겼다. 지금은 증서를 따기 위해 고민할 필요가 없고 안정적으로 서비스를 제공할 수 있다. 나는 이미 만 살이다.
...그리고 그는 이후 여러 개의 이름 공간으로 나뉘어진 각 환경의 버전 관리와 활용에 더욱 고생할 것이다. 이것은 또 다른 이야기다.