도메인과 서브도메인이 늘면서 GCP 관리형 인증서로는 감당이 안 되자, Let's Encrypt 와일드카드 인증서를 GKE CronJob 으로 자동 발급·갱신해 GCLB 에 붙인 구성을 정리한 글이다.
핵심 포인트- GCP 관리형 인증서는 소수 도메인에는 적합하지만 와일드카드(`*.example.com`) 를 지원하지 않는다.
- 쿠키 이슈 때문에 프론트에서 (서비스 수 × 개발자 수) 만큼 서브도메인을 독립 할당해야 하는 상황이 되면서 관리형으로는 버티기 어려워졌다.
- 유료 인증서도 갱신 등 손이 많이 가므로, 초기 세팅만 넘기면 유지보수가 가장 쉬운 Let's Encrypt 를 골랐다.
- 발급은 certbot 이 담긴 컨테이너를 GKE CronJob 으로 돌려 처리하고, 발급된 인증서를 GCLB 에 복사해 실제로 사용하도록 설정한다.
- DNSSEC 을 쓰고 있었다면 먼저 해제해야 하며 이 과정만 약 2일 이상 걸린다.
상세 정리- DNS 준비: Google Cloud DNS 에 DNS Zone 을 만들고, 생성된 NS 레코드의 네임서버 주소를 도메인 구입처의 Name Server 목록에 등록한다.
- 네임서버 주소의 `ns-cloud-b` 부분은 a~e 까지 경우에 따라 다르게 나온다는 점을 짚는다.
- 권한 준비: IAM 에서 Service Account 를 새로 만들어 필요한 권한을 부여하고 key 파일을 내려받는다.
- 그 키 파일을 사용할 클러스터·네임스페이스에 secret 으로 등록한다.
- CronJob 구성: 시작 시 해당 secret 을 읽을 수 있도록 설정하고, `cert.sh` 를 실행하도록 만든다. 이 스크립트가 사실상의 코어다.
- 이미지 구성: 우분투 베이스에 gcloud 와 certbot 을 설치해야 해서 Dockerfile 의 설치 단계가 다소 복잡하다.
- `cert.sh` 가 하는 일은 세 가지다. certbot 으로 인증서를 발급받고, 발급된 인증서를 GCLB 에 복사하고, 그 인증서를 실제로 사용하도록 설정한다.
- 알려진 부작용: 이 방식은 만료된 인증서 찌꺼기가 디렉터리에 남는다. 1년에 한 번쯤 들어가 일괄 삭제하면 된다고 정리한다.
- 글의 동기를 "검색해도 안 나와서 정리했다" 로 밝힌다.
왜 읽나서브도메인이 계속 늘어 관리형 인증서로 감당이 안 되는 GKE 사용자에게 와일드카드 자동 갱신 구성을 통째로 보여준다.