Temporal CA Certificate 교체하기

인증서는 교체되어야 한다, 언젠가는…

Chris Lee

Published in

DelightRoom

11 min readNov 15, 2023

작성자: Chris -Backend Lead Engineer DelightRoom

위기

어느 서늘한 가을날, Temporal Cloud 로부터 아래와 같은 경고 메일이 오기 시작하였습니다.

살펴보니 기존 사용하던 certificate가 약 1년전에 만든것으로 유효기간이 거의 다 되어가고 있었습니다.

참고로 certificate 의 정확한 유효기간은 openssl 터미널 명령어로 확인할 수 있어요.

$ openssl x509 -in ca.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            58:78:12:b0:c9:aa:15:dd:11:bd:f2:e2:48:b5:27:dc:3b:8b:e0:58
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: O = DelightRoom
        Validity
            Not Before: Nov  8 18:23:15 2022 GMT
            Not After : Nov  8 18:23:15 2023 GMT
        Subject: O = DelightRoom
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:b4:b9:5f:8f:6e:de:b1:99:f5:10:0b:8e:d5:ac:
...

GMT 기준 2023년 11월 8일 16시 23분 15초이므로 한국시간 11월 9일 새벽이면 유효기간이 도래한다고 보면 됩니다. 어서 교체를 하지 않으면 중요 서비스들이 동작을 중단할 수 있습니다!

잠깐! ✋️ 갑자기 Temporal, Cloud 등등이 나오는데… 그게 뭔가요?

Temporal은 애플리케이션 코드의 durable execution을 가능케 해주는 일종의 플랫폼 및 기반 기술입니다. Temporal Cloud는 오픈 소스인 이 기술의 Cloud offering입니다. 이에 대해서는 별도의 글에서 자세히 다뤄보겠습니다. 이 글을 위해서는 외부의 Temporal Cloud Server와 우리 내부 애플리케이션인 Temporal Worker가 mTLS 를 사용하여 소통하므로 인증서 관리가 필요하다는 사실만 알고 계시면 되겠습니다.

자료 조사

약 1년 전 Temporal 도입 초기에 사용했던 방법 그대로 certificate들을 다시 생성하고 업데이트 해 줄 수도 있겠지만, 이 교체 과정을 더 효율적이고, 체계적으로 진행하기 위해 간단한 자료 조사를 해 보았습니다.

다음 Temporal 공식 문서에서는 Temporal Cloud 사용시 certificate 관리에 있어 전반적인 고려사항과 How-to들을 설명 해 주고 있습니다.

How to manage certificates in Temporal Cloud | Temporal Documentation

Temporal 의 Solution Architect 인 Keith Tenzer 의 블로그에서는 CA certificate rotation을 하고 싶은 사람들에게 특화된 글을 찾을 수 있었습니다.

Temporal Cloud Certificate Rotation

조금 덜 복잡해보이고 친절해보이는 두번째 글을 참고하여 한번 certificate 교체를 진행해보겠습니다.

Certificate 교체

CA certificate 교체는 크게 다음과 같은 과정으로 이루어집니다.

새 CA certificate 생성
CA certifcate를 서버에 업로드
클라이언트에서 사용할 Leaf certificate 생성
새 Leaf certificate을 사용하도록 클라이언트 업데이트
작동확인
기존의 만료가 임박한 CA certificate 삭제

CA certificate 생성

Temporal 서버(우리의 경우에는 Temporal Cloud 서버)에 올라가게 되는 CA certificate의 갱신이 먼저 필요합니다. 친절하게도 Cloud를 사용중이라면 만료 10일 전부터 안내 메일이 오게됩니다.

tcld

Certificate을 생성하는 방법은 여러가지가 있습니다. 먼저 Temporal Cloud를 위한 CLI 툴인 tcld (https://github.com/temporalio/tcld) 를 한번 시도해 보았습니다.

$ tcld gen ca --org DelightRoom -d 1y --ca-cert ca.pem --ca-key ca.key

원하는 위치에서 위 명령어를 사용하여 CA certificate를 간편하게 생성할 수 있습니다.

안타깝게도 이렇게 생성한 CA는 이번에 사용할 수 없었습니다. 왜냐하면 기존의 certificate과 동일한 subject (“O=DelightRoom”)의 CA certificate이 번들에 추가되는 것이 허용되지 않았기 때문이었어요. 물론 다른 org로 만들어서 올리면 가능하겠지만 org는 그대로 유지하고 싶었습니다. 대안으로 common name 과 같은 다른 속성을 바꿔보려 했으나 tcld에서 아직 지원하지 않았습니다.

certstrap

그래서 대안인 certstrap (https://github.com/square/certstrap) 으로 선회하였습니다.

$ certstrap init --common-name DelightRoomCertAuth \\
  --organization DelightRoom --expires "3 years"

Created out/DelightRoomCertAuth.key
Created out/DelightRoomCertAuth.crt
Created out/DelightRoomCertAuth.crl

위 명령어는 DelightRoomCertAuth 라는 CN을 가진 CA certificate 을 생성합니다. 유효기간은 3년으로 지정해 주었습니다. 기본적으로 위와 같이 out 폴더에 생성됩니다.

CA certificate 업로드

tlcd는 namespace에서 사용할 CA certificate을 업로드 하는 기능도 제공합니다. 그러므로 이를 활용해보겠습니다. 조심해야할 점은 기존 CA certificate에 붙어있는 Worker, API 서버등 Temporal 클라이언트들이 활성상태일 것 이므로 기존것을 지우지 않고 추가만 해야 합니다.

다음 명령어는 Temporal Cloud 상의 primary-prod.xAxPa 라는 namespace에서 사용하는 CA certificate list에 새 certificate을 추가해줍니다.

$ tcld n ca add --namespace primary-prod.xAxPa -f out/DelightRoomCertAuth.crt

클라이언트에서 사용할 Leaf certificate 생성

이제 해당 CA 를 통해 인증될 leaf certificate을 생성하여 클라이언트에서 사용할 수 있도록 해봅시다. 이때도 certstrap을 사용 할 것입니다. 아까와 같은 디렉토리 안에서 계속 진행하겠습니다. 그러면 out 폴더가 마치 staging 영역처럼 그 안에 있는 crt, key가 그대로 활용됩니다.

일단 certificate request를 만듭니다. Common name은 namespace 이름으로 해봅시다.

$ certstrap request-cert --common-name primary-prod.xAxPa

Created out/primary-prod.xAxPa.key
Created out/primary-prod.xAxPa.csr

그 후 새 CA의 key로 signing을 진행합니다.

$ certstrap sign primary-prod.xAxPa --CA DelightRoomCertAuth

Created out/primary-prod.xAxPa.crt from out/primary-prod.xAxPa.csr signed by out/DelightRoomCertAuth.key

이제 Temporal 클라이언트에서는 생성된 primary-prod.xAxPa.key , primary-prod.xAxPa.crt 를 활용하면 됩니다!

바로 실전에 투입하기는 조금 불안하므로 잘 동작할 지 미리 테스트 해볼 수 있습니다. Temporal CLI 툴 (https://github.com/temporalio/cli) 을 사용하면 아래와 같이 비교적 간편하게 테스트가 가능합니다. 문제가 있다면 인증서 오류가 납니다.

$ temporal workflow list --address primary-prod.xAxPa.tmprl.cloud:7233 --namespace primary-prod.xAxPa --tls-cert-path out/primary-prod.xAxPa.crt --tls-key-path out/primary-prod.xAxPa.key

클라이언트 측 certificate 업데이트

이제 클라이언트들이 사용하는 certificate들을 새로 생성한 leaf certificate으로 교체 해주어야 합니다. 이 과정은 실제로 어떻게 설정이나 비밀값들을 배포 환경에 적용하고 있냐에 따라 많이 달라질 수 있습니다. 저희는 Doppler → External Secret → K8s Secret 를 통해 비밀값들을 주입하고 있기 때문에 비교적 간편하게 수정이 가능했습니다.

이 과정에서도 이슈가 생길 수 있기 때문에 기존에 돌던 클라이언트들을 바로 제거 하기 보다는 서서히 새 certificate 사용하는 복제본을 늘리는 방식으로 배포하는 것을 권합니다.

업데이트 후, 기존 certificate을 사용하는 클라이언트가 모두 꺼질때까지 모니터링합니다.

기존 CA certificate 제거

기존 certificate를 사용하는 클라이언트가 없음을 확인 하였다면, 이제 namespace에서 기존의 만료가 임박한 CA certificate을 제거할 수 있습니다. 직접 Temporal Cloud의 Web UI를 통해 제거할 수도 있고, 간편하게 다음과 같은 터미널 명령어를 사용 할 수도 있습니다.

$ tcld n ca remove --namespace primary-prod.xAxPa -f old_ca.pem

이 때 기존 CA certificate 가 필요하므로 만약 로컬에 없다면 미리 준비할 수 있도록 합니다.

후속 작업

별도의 Certificate 관리 인프라를 사용하지 않는 저희와 같은 소규모 기업의 경우, 위 처럼 인증 체계를 수동으로 점검 및 업데이트 해주어야 하는 부담이 있습니다. 그리고 이 과정에는 사람의 실수와 같은 잠재적인 위험성이 존재합니다. 예를 들어서 관리자에게 인증서 만료 경고 메일이 왔지만, 메일을 놓치거나 스팸함에 가버렸다면? 자칫 중요한 서비스의 갑작스런 중단을 겪을 수도 있습니다.

이러한 문제를 해소하기 위해 다음과 같은 후속 작업을 진행 예정입니다.

현재 사용중인 CA 및 leaf certificate에 대한 자체적인 만료 위험 체크 및 경고 알림 시스템 구축
만료 기간보다 더 짧은 주기로, 주기적으로 certificate을 자동 업데이트하여 사용하도록 rotation 자동화

추후 인증서의 개수가 너무 많아지거나 하는 등의 이유로 관리가 힘들어지면 비용을 지불하더라도 별도의 인증서 관리 시스템을 도입하는 것도 방법이 되겠습니다.

마무리

이 글에서는 Temporal Cloud 사용시에 CA certificate를 교체하는 방법을 알아보았습니다. Temporal Cloud를 사용하든 직접 운영하든 아마도 certificate을 주기적으로 교체해야 할 필요가 생기실 텐데 요. 이 글이 그러한 경우를 겪는 Temporal 사용자들에게 조금이나마 도움이 되었길 바랍니다.

Temporal과 같은 흥미로운 최신기술 활용에 관심있는 백엔드 개발자라면 주목!
⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다.