이 페이지에서는 Google Distributed Cloud (GDC) 오프라인 웹 엔드포인트의 인증서 재발급을 수동으로 트리거하는 방법을 설명합니다.
시작하기 전에
네임스페이스의 인증서에 액세스하는 데 필요한 권한을 얻으려면 조직 IAM 관리자에게 웹 TLS 인증서 관리자 (web-tls-cert-admin
) 역할을 부여해 달라고 요청하세요.
인증서를 재발급할 때는 다음 계정 요구사항을 고려하세요.
- 인프라 운영자 (IO) 계정을 사용하여 시스템 네임스페이스의 인증서에 액세스합니다. IO에게 이 작업을 실행해 달라고 요청하세요.
- 플랫폼 관리자 계정을 사용하여 다른 네임스페이스의 인증서에 액세스합니다.
인증서 재발급
주석 업데이트를 사용하여 인증서를 수동으로 다시 발급할 수 있습니다. 기본 인증서 발급자가 변경되면 인증서가 만료되지 않는 한 Distributed Cloud는 이전 기본 인증서 발급자가 서명한 인증서를 자동으로 재발급하지 않습니다.
인증서 재발급을 수동으로 트리거하려면 kubectl
CLI를 사용하여 다음 단계를 실행하세요.
타겟
Certificate
의manual-reissuance
주석을requested
로 설정합니다. 다음 예에서는 현재 기본 인증서 발급자를 사용하는istio-system
네임스페이스의default-wildcard-cert
인증서를 업데이트합니다.kubectl annotate --overwrite certificate.pki.security.gdc.goog default-wildcard-cert -n istio-system pki.security.gdc.goog/manual-reissuance='requested'
인증서가 재발급되는 동안
in-progress
주석 값이 전환 상태로 표시될 수 있습니다.manual-reissuance
주석 값이finished
로 표시될 때까지 기다립니다.kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r ' .metadata.annotations."pki.security.gdc.goog/manual-reissuance"'
결과는 다음과 유사합니다.
finished
인증서 발급자를 확인합니다. 인증서 사양에 언급된 발급자와 일치해야 하며, 지정되지 않은 경우 발급자는 현재 기본 발급자와 일치해야 합니다.
kubectl -n istio-system get certificate.pki.security.gdc.goog/default-wildcard-cert -ojson | jq -r ' .status.issuedBy'
결과는 다음과 유사합니다.
{ "name": "byo-cert-issuer", "namespace": "pki-system" }
자체 인증서 가져오기 수동 순환
수동 자체 인증서 사용 (BYO cert) 순환을 트리거하고 완료할 때는 이전에 서명된 BYO cert에 대해 새로 생성된 인증서 서명 요청 (CSR)에 서명해야 합니다. 자세한 내용은 BYO 인증서 서명을 참고하세요.
교체 중에 Distributed Cloud는 새 비공개 키와 공개 키 쌍을 만듭니다. 따라서 이전에 업로드된 서명된 인증서가 새 CSR과 호환되지 않습니다. 초기 업로드 이후 인증서 사양이 변경되지 않은 경우 이전에 업로드된 인증서는 만료될 때까지 계속 사용됩니다. 사양이 변경되면 다음 이벤트 중 하나가 발생합니다.
- Distributed Cloud는 일치하는 기존 인증서를 사용합니다.
- 대체 인증 기관 (CA)에서 새 인증서를 발급합니다.
BYO 인증서 수동 순환 예시
다음 예에서는 수동 순환을 위해 트리거된 이전에 서명된 BYO 인증서를 확인할 수 있습니다.
byoCertStatus
에 인증서type
값이Ready
로 표시됩니다.reason
값은 이전 값보다lastTransitionTime
값이 더 빠른Issued
입니다.{ "byoCertStatus": { "csrStatus": { "conditions": [ { "lastTransitionTime": "2024-05-03T22:38:43Z", "message": "", "observedGeneration": 2, "reason": "WaitingForSigning", "status": "False", "type": "Ready" } ], "csr": "LS0tLS1CRUdJTiBDRVJ..." }, "signedCertStatus": { "conditions": [ { "lastTransitionTime": "2024-05-03T22:38:43Z", "message": "RawSubjectPublickKeyInfo does not match with the CSR", "observedGeneration": 2, "reason": "Rejected", "status": "False", "type": "Ready" } ] } }, ```
다음 예시에서는 수동 순환을 위해 트리거된 이전에 서명된 BYO 인증서의 출력을 보여줍니다.
signedCertStatus
에서reason
필드는Rejected
를 보여줍니다. 이는 이전에 서명된 인증서가 순환 후 새 CSR과 더 이상 일치하지 않기 때문입니다.CSR
reason
에는WaitingForSigning
이 명시되어 있습니다."conditions": [ { "lastTransitionTime": "2024-05-03T08:42:10Z", "message": "Certificate is issued", "observedGeneration": 2, "reason": "Issued", "status": "True", "type": "Ready" } ], "errorStatus": { "errors": [ { "code": "PLATAUTH2002", "message": "Waiting for CSR signing" } ], "lastUpdateTime": "2024-05-03T22:38:43Z" }, "issuedBy": { "name": "byo-cert-issuer", "namespace": "pki-system" } }
인증서 서명 알림 관리
초기 발급, 순환, 만료에 대한 인증서 서명 알림은 PKI 런북의 다음 섹션에 설명된 문제 해결 단계를 사용하여 IO에서 처리해야 합니다.
하위 CA errorCode:
PLATAUTH2001
의 경우 PLATAUTH-R2001을 참고하세요.BYO 인증서 오류 코드
PLATAUTH2002
의 경우 PLATAUTH-R2002를 참고하세요.