Red Hat Blog에 관심가는 글이 올라와서 AI 번역+살짝 교정해봤습니다.
출처: https://developers.redhat.com/articles/2025/09/24/automate-certificate-management-openshift
현대 IT 환경에서 인증서 관리는 끊임없는 과제입니다. 소수의 클러스터를 사용하는 DevOps 엔지니어, SRE, IT 관리자의 경우, 이는 종종 시간이 많이 소요되는 수동 작업입니다. 표준화되고 자동화된 프로세스가 없다면 애플리케이션 사용자는 조직의 지침이 아닌 자신의 선호도에 따라 인증서를 생성할 수 있으며, 이는 심각한 거버넌스 및 보안 위험을 초래할 수 있습니다. 해결책은 더 빠르게 작업하는 것이 아니라 자동화하는 것입니다. 이 문서에서는 Venafi와 함께 Red Hat OpenShift용 cert-manager 오퍼레이터를 사용하여 Red Hat OpenShift 에서 전체 인증서 수명 주기를 자동화하는 방법을 살펴보겠습니다. 이를 통해 플랫폼 및 애플리케이션 인증서 모두에 안전하고 확장 가능한 솔루션을 제공합니다.
수백 개 또는 수천 개의 클러스터를 관리할 때 수동 인증서 관리는 심각한 병목 현상을 초래합니다. 이러한 방식은 인적 오류가 발생하기 쉽고, 인증서 만료, 예상치 못한 다운타임, 그리고 환경 전반의 보안 태세 불안정으로 이어질 수 있습니다. 선언적이고 정책 기반의 인증서 관리 방식은 역동적인 하이브리드 클라우드 환경에서 규정 준수, 민첩성 및 복원력을 보장할 수 있습니다.
부인 성명: 이 문서에 언급된 cert-manager 연산자는 Red Hat에서 지원하는 인증서 관리자 연산자입니다. IBM 인증서 관리자 연산자가 Red Hat 인증서 관리자와 함께 클러스터에 존재하지 않도록 해야 합니다. 두 연산자는 서로 충돌하여 기능에 영향을 미치기 때문입니다. 또한, 이 문서에서 다루는 플랫폼 인증서는 주로 API 인증서와 Ingress 인증서입니다. 클러스터 내부에서 노드 간 통신이나 etcd 통신에 사용하는 인증서는 언급하지 않습니다.
기존 인증서 관리 vs. 현대 인증서 관리
전통적인 인증서 관리에서 현대적인 인증서 관리로 인증서 관리가 어떻게 발전했는지 살펴보겠습니다.
전통적(과거):
- 수동 요청 및 다운로드
- CLI/스크립트 기반
- 시간이 많이 걸리는 갱신
- 오류가 발생하기 쉽다
- 지속적인 지원 및 유지 관리
현대적(새로운):
- 자동 요청
- 선언적 YAML
- 컨트롤러를 통한 자동 갱신
- 정책 중심적이고 감사 가능
- 일회성 설정 및 구성
이 새로운 접근 방식은 수동적이고 많은 노력이 필요한 모델에서 선제적이고 유지 관리가 적은 모델로 전환하는 것입니다. 이를 통해 팀은 수동적이고 반복적인 작업에서 벗어나 혁신에 집중할 수 있습니다.
자동화된 워크플로에 대한 심층 분석
cert-manager 운영자는 OpenShift와 기본적으로 통합되어 인증서 관리를 간소화합니다. 인증서 발급부터 갱신까지 원활하게 자동화된 수명 주기를 제공합니다. Venafi TPP와 같은 강력한 외부 발급자와 결합하면 엔터프라이즈급 보안 및 신뢰성을 제공합니다. 전체 프로세스는 선언적으로 처리되므로 모든 작업이 기록되고 감사 가능합니다.
자동 인증서 관리를 설정하려면 다음 단계를 따르세요.
1단계: cert-manager 운영자 설치
첫 번째 단계는 cert-manager 연산자를 설치하는 것입니다. OpenShift OperatorHub에서 찾을 수 있습니다. 연산자는 자동으로 두 개의 네임스페이스(cert-manager-operator와 cert-manager)를 생성합니다 . 연산자와 해당 컨트롤러 리소스는 cert-manager 네임스페이스에서 실행되며 모든 구성 및 인증서 리소스는 해당 네임스페이스에 생성됩니다.
2단계: Venafi 연결 비밀번호 생성
Venafi 팀과 협력하여 Venafi TPP 플랫폼을 설정하여 서비스 ID 및 각 엔드포인트에 필요한 권한을 부여해야 합니다. 자세한 내용은 cert-manager 문서를 참조하세요.
우리는 https://tpp.example.com/vedauth/authorize/oauth 엔드포인트를 사용하여 액세스 토큰을 생성합니다.
cert-manager가 Venafi TPP와 통신할 수 있도록 하려면 인증을 위한 액세스 토큰을 저장하는 Kubernetes 시크릿을 만들어야 합니다.
apiVersion: v1 kind: Secret metadata: name: venafi-tpp-secret namespace: cert-manager type: Opaque stringData: access-token: "YOUR-VENAFI-ACCESS-TOKEN"
oc apply -f <filename>을 사용하여 이 시크릿을 클러스터에 적용합니다 .
참고: 서비스 ID에 필요한 Venafi TPP 엔드포인트와 RBAC를 활성화하고 액세스가 정확하게 설정되었는지 테스트하는 데 상당한 시간이 걸렸습니다.
3단계: Venafi 정책으로 ClusterIssuer 만들기
리소스 ClusterIssuer는 인증서를 발급할 인증 기관을 나타냅니다. 이 경우, Venafi 엔드포인트, 인증서 정책 영역, 그리고 이전 단계에서 생성한 비밀에 대한 참조로 구성된 Venafi TPP입니다.
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: venafi-internal-1year
spec:
venafi:
tpp:
cabundle: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
url: https://venafi-tpp.example.com/VEDSDK
credentialsRef:
name: venafi-tpp-secret
zone: "\VED\PolicyCertifiactes\cert-manager\Internal\1year"이 YAML을 적용하면 ClusterIssuer가 생성됩니다 상태가 Ready: True로 바뀌면 인증서를 발급할 준비가 된 것입니다.
4단계: 인증서 리소스 만들기
Certificate이제 특정 네임스페이스에 애플리케이션이나 플랫폼용 리소스를 생성할 수 있습니다 . 이 리소스는 cert-manager에 어떤 인증서를 요청해야 하는지, 그리고 요청된 TLS 비밀번호를 어디에 저장해야 하는지 알려줍니다. 이 방식을 사용하면 Kubernetes 네이티브 리소스를 사용하여 인증서를 쉽게 프로비저닝할 수 있습니다.
다음 예는 openshift-ingress 네임스페이스에 생성된 OpenShift Ingress 인증서에 대한 것입니다.
이는 Ingress 컨트롤러를 위한 와일드카드 인증서이며 웹 콘솔과 CLI 액세스에 사용됩니다.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: ocp-apps-cert
namespace: openshift-ingress
spec:
commonName: "*.apps.ocp.example.com". # Wild card certificate
dnsNames:
- "*.apps.ocp.example.com"
issuerRef:
group: cert-manager.io
name: venafi-internal-1year # Clusterissuer issuing certificate with
# 1 yr validity
kind: ClusterIssuer
privateKey:
algorithm: RSA
encoding: PKCS1
size: 2048
renewBefore: 360h0m0s # Renewal period when certificate will be renewed
secretName: ocp-app-cert-secret # Secret name that stored certiticate details참고: 와일드카드 인증서에는 기간을 제한하고 더 자주 갱신하도록 요구하는 특별 정책이 있을 수 있습니다.
다음 인증서는 API 서버용이며 openshift-config 네임스페이스에 생성해야 합니다.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: ocp-api-cert
namespace: openshift-config
spec:
commonName: "api.ocp.example.com". # Wild card certificate
dnsNames:
- "api.ocp.example.com"
issuerRef:
group: cert-manager.io
name: venafi-internal-1year # Clusterissuer issuing certificate with
# 1 yr validity
kind: ClusterIssuer
privateKey:
algorithm: RSA
encoding: PKCS1
size: 2048
renewBefore: 360h0m0s # Renewal period when certificate will be renewed
secretName: ocp-api-cert-secret # Secret name that stored certiticate details해당 리소스가 적용되면 cert-manager 운영자는 Venafi TPP와 통신하고 인증서를 발급하며 TLS 키와 인증서를 해당 ocp-app-cert-secret과 ocp-api-cert-secret 네임스페이스에 저장 합니다.
발급된 인증서에는 인증서 생성 날짜/시간, 만료 날짜/시간, 갱신 날짜/시간도 제공됩니다. Certificate 리소스 상태가 status: True로 표시됩니다.
인증서 리소스의 상태 세부 정보 예:
status:
conditions:
- type: Ready
status: "True"
reason: Ready
message: Certificate is up to date and has not expired
lastTransitionTime: "2025-06-20T14:03:00Z"
notAfter: "2025-10-09T15:40:41Z"
notBefore: “2025-07-11T15:40:41Z”
renewalTime: "2025-09-19T15:40:41Z"5단계: OpenShift 인증서 패치
새로운 인증서 비밀이 생성되면 OpenShift API 서버와 Ingress 컨트롤러를 업데이트하여 사용할 수 있습니다.
openshift-ingress-operator네임스페이스의defaultIngressController는 openshift-ingress 네임 스페이스에서 생성된 ocp-app-cert-secret 시크릿으로 패치됩니다 .clusterAPIServer 리소스는openshift-config네임스페이스에서 생성된ocp-api-cert-secret시크릿으로 패치됩니다 .
다음 oc patch 명령을 사용하여 새로 생성된 시크릿을 적용합니다.
# Patch the Ingress Controller
oc patch ingresscontroller.operator.openshift.io default \
--type=merge -p '{"spec":{"defaultCertificate":{"name":"ocp-app-cert-secret"}}}' \
-n openshift-ingress-operator# Patch the API Server
oc patch apiserver.operator.openshift.io cluster \
--type=merge -p '{"spec":{"servingCerts":{"namedCertificates":[{"names":["api.ocp.example.com"], "servingCertificate": {"name": "ocp-api-cert-secret"}}]}}}'패치 후 Ingress 포드가 다시 시작되어 새 인증서를 받았는지 확인하고, API 서버의 경우 모든 마스터 노드에 kube-apiserver ClusterOperator의 새 버전이 롤아웃되었는지 확인합니다.
리소스 패치에 대한 자세한 내용은 설명서 를 참조하세요 .
추가 생태계로 자동화를 확보합니다
플랫폼 인증서를 관리할 때는 자동화 생태계의 모든 구성 요소가 예상대로 작동하는지 확인하는 것이 중요합니다. cert-manager 포드나 Venafi 액세스 토큰 갱신 프로세스와 같은 구성 요소에 오류가 발생하면 인증서 발급 또는 갱신을 위한 전체 워크플로가 중단되어 플랫폼 다운타임이 발생할 수 있습니다.
이러한 문제를 해결하고 자동화 시스템의 무결성을 유지하기 위해 다음과 같은 제어 기능을 구현했습니다.
- 사전 예방적 액세스 토큰 갱신 : 중단을 방지하기 위해 Venafi 액세스 토큰을 월별 만료일보다 훨씬 앞서 15일마다 갱신하도록 cron 작업이 설정되었습니다.
- 자동 알림 : 토큰 갱신을 위한 크론 작업이 실패하면, 알림 관리자를 사용하여 즉각적인 개입이 가능하도록 운영 팀에 중요한 알림이 전달됩니다.
- 구성 요소 모니터링 : cert-manager 포드의 상태를 모니터링하고 오류가 발생하면 운영 팀에 직접 보고하도록 구성된 Splunk 알림입니다.
- 향상된 가시성 : 모든 인증서의 생성, 만료, 갱신 날짜/시간을 포함하여 명확하게 볼 수 있도록 개발된 보고 UI입니다. 이 도구는 가시성을 간소화하고 모든 클러스터의 모든 인증서 상태를 추적하는 데 도움이 됩니다.
- 스마트 알림 : 보고 도구는 갱신이 예정되면 인증서 소유자에게 자동으로 이메일 알림을 보내고, 지정된 시간 내에 갱신이 이루어지지 않으면 경고 이메일을 보냅니다.
애플리케이션에 자동화 확장
cert-manager가 인증서 수명 주기를 자동화하는 반면, 애플리케이션 팀의 과제는 새 인증서를 발급할 때 애플리케이션과 서비스를 업데이트하는 것입니다. 또한, 참조된 비밀번호가 변경되어도 애플리케이션 포드가 자동으로 재시작되거나 다시 로드되지 않아 갱신된 인증서를 적용하기 위해 수동으로 재시작해야 하는 경우가 많습니다. 바로 이 부분에서 커뮤니티 지원 운영자가 도움을 줄 수 있습니다.
Cert-Utils 오퍼레이터 프로젝트
커뮤니티 지원 프로젝트인 Cert-Utils Operator는 애플리케이션 팀의 여러 주요 작업을 자동화합니다. 일반적으로 kubernetes.io/tls 유형의 쿠버네티스 시크릿으로 제공되는 인증서를 사용합니다 . 핵심 기능 중 하나는 OpenShift 경로에 인증서를 채우는 것입니다. 에지 또는 재암호화 종료가 있는 경로의 경우, 이 연산자는 기본 시크릿이 변경되면 주석을 사용하여 경로의 TLS 키와 인증서를 자동으로 업데이트합니다.
이 기능은 수동 개입이 필요했던 프로세스를 간소화합니다. 또한, 운영자는 다음과 같은 유용한 기능도 제공합니다.
- Java 키스토어/트러스트스토어 생성 : 인증서로부터 Java 키스토어 및 트러스트스토어 파일을 생성할 수 있습니다.
- CA 번들 주입: CA 번들을
Secrets,ConfigMaps,CustomResourceDefinition객체 와 같은 다양한 Kubernetes 객체에 주입할 수 있습니다 . - 인증서 만료 알림 : 인증서가 만료되기 직전에 알림을 생성할 수 있습니다.
이러한 기능은 리소스에 대한 옵트인 주석을 통해 활성화됩니다.
사용할 수 있는 주석의 예는 다음과 같습니다.
cert-utils-operator.redhat-cop.io/certs-from-secret: "tls-secret" cert-utils-operator.redhat-cop.io/destinationCA-from-secret: "tls-secret"
Reloader 오퍼레이터
Reloader 오퍼레이터는 구성 변경 후 Pod를 수동으로 다시 시작하는 문제를 해결합니다. ConfigMap 또는 Secret의 변경 사항을 감시하고 Deployment, DaemonSet, StatefulSet과 같은 관련 워크로드의 롤링 업데이트를 자동으로 수행합니다.
cert-manager가 새 인증서를 발급하면 시크릿이 업데이트됩니다. Reloader는 이러한 변경 사항을 감지하고 해당 시크릿을 참조하는 Pod에 롤링 업데이트를 실행하여 수동 개입 없이 항상 최신 인증서를 사용하도록 합니다. 이는 인증서 갱신 프로세스의 중요한 단계를 자동화하므로 애플리케이션 및 미들웨어 팀에 특히 유용합니다. 또한 이 연산자는 주석을 기반으로 작동합니다.
예를 들어, 이름이 ”my-cert-secret”을 사용하는 배포에서 Reloader를 활성화하려면 다음 주석을 추가합니다.
secret.reloader.stakater.com/reload: "my-cert-secret"
이 오퍼레이터는 프로덕션 환경을 위한 서비스 수준 계약(SLA)과 인증된 이미지를 제공하는 엔터프라이즈 버전을 제공합니다.
커뮤니티 오퍼레이터
커뮤니티 지원 프로젝트의 사용에 대해 투명성을 확보하는 것이 중요합니다. 이러한 오퍼레이터는 강력하고 널리 사용되지만, Red Hat은 이러한 오퍼레이터에 대한 직접적인 지원을 제공하지 않습니다. 지원은 “최선을 다하는” 방식으로 제공됩니다. 그러나 선언적이고 주석 기반 접근 방식은 OpenShift 운영 모델과 완벽하게 일치하며 플랫폼 및 애플리케이션 보안 태세를 크게 향상시킵니다.
마지막 생각
Red Hat OpenShift 및 Venafi용 cert-manager 오퍼레이터를 사용하여 인증서 관리를 자동화하면 수동 프로세스의 위험과 비효율성을 제거하는 안전하고 확장 가능한 솔루션을 제공합니다. 중앙에서 제어하고 일관성을 보장하며, 팀이 반복적이고 오류가 발생하기 쉬운 작업 대신 혁신에 집중할 수 있도록 지원합니다. 선언적 구성과 OpenShift 네이티브 도구의 강력한 기능을 활용하여 조직의 규모에 맞춰 확장 가능한 더욱 탄력적이고 민첩한 플랫폼을 구축할 수 있습니다.
