4.3. 서비스 CA 인증서
4.3.1. 목적
service-ca
는 OpenShift Container Platform 클러스터가 배포될 때 자체 서명된 CA를 만드는 Operator입니다.
4.3.2. 만료
사용자 정의 기간은 지원되지 않습니다. 자체 서명된 CA는 tls.crt
(인증서), tls.key
(개인 키) 및 ca-bundle.crt
(CA 번들)의 규정된 이름 service-ca/signing-key
로 보안에 저장됩니다.
다른 서비스에서는 service.beta.openshift.io/serving-cert-secret-name: <secret name>
으로 서비스 리소스에 주석을 달아 서비스 제공 인증서를 요청할 수 있습니다. 이에 응답하여 Operator는 이름 지정된 보안에 대한 tls.crt
로 새 인증서를, tls.key
로 개인 키를 생성합니다. 이 인증서는 2년간 유효합니다.
다른 서비스에서는 서비스 CA에서 생성된 인증서의 검증을 지원하기 위해 service.beta.openshift.io/inject-cabundle: true
로 주석을 달아 서비스 CA의 CA 번들을 API 서비스 또는 구성 맵 리소스에 삽입하도록 요청할 수 있습니다. 이에 응답하여 Operator는 현재 CA 번들을 API 서비스의 CABundle
필드에 쓰거나 service-ca.crt
로 구성 맵에 씁니다.
OpenShift Container Platform 4.3.5부터 자동 순환이 지원되며 일부 4.2.z 및 4.3.z 릴리스로 백포트됩니다. 자동 순환을 지원하는 모든 릴리스에서 서비스 CA는 26개월 동안 유효하며 유효 기간이 13개월 미만으로 남아 있으면 자동으로 새로 고칩니다. 필요하면 서비스 CA를 직접 새로 고칠 수 있습니다.
26개월의 서비스 CA 만료 기간은 지원되는 OpenShift Container Platform 클러스터에 대한 업그레이드 예상 간격보다 길기 때문에 서비스 CA 인증서의 비컨트롤 플레인 소비자의 CA는 CA 순환 후와 순환 전 CA 만료 전에 새로 고칩니다.
수동으로 순환된 서비스 CA는 이전 서비스 CA와의 신뢰를 유지 관리하지 않습니다. 클러스터의 Pod가 다시 시작되어 Pod가 새 서비스 CA에서 발급한 서비스 제공 인증서를 사용하고 있는지 확인할 때까지 일시적으로 서비스 중단이 발생할 수 있습니다.
service-ca
인증서를 사용하는 애플리케이션은 CA 인증서를 동적으로 다시 로드할 수 있어야 합니다. 그렇지 않으면 자동 순환이 발생하면 인증서 신뢰를 다시 빌드하기 위해 애플리케이션 Pod를 다시 시작해야 할 수 있습니다.
4.3.3. 관리
이러한 인증서는 사용자가 아닌 시스템에서 관리합니다.
4.3.4. 서비스
서비스 CA 인증서를 사용하는 서비스는 다음과 같습니다.
- cluster-autoscaler-operator
- cluster-monitoring-operator
- cluster-authentication-operator
- cluster-image-registry-operator
- cluster-ingress-operator
- cluster-kube-apiserver-operator
- cluster-kube-controller-manager-operator
- cluster-kube-scheduler-operator
- cluster-networking-operator
- cluster-openshift-apiserver-operator
- cluster-openshift-controller-manager-operator
- cluster-samples-operator
- machine-config-operator
- console-operator
- insights-operator
- machine-api-operator
- operator-lifecycle-manager
이것은 포괄적인 목록이 아닙니다.