3장. 인증서 구성
3.1. 기본 수신 인증서 교체 링크 복사링크가 클립보드에 복사되었습니다!
3.1.1. 기본 수신 인증서 이해 링크 복사링크가 클립보드에 복사되었습니다!
기본적으로 OpenShift Container Platform에서는 Ingress Operator를 사용하여 내부 CA를 생성하고 .apps
하위 도메인의 애플리케이션에 유효한 와일드카드 인증서를 발급합니다. 웹 콘솔과 CLI도 모두 이 인증서를 사용합니다.
내부 인프라 CA 인증서는 자체 서명됩니다. 이 프로세스는 일부 보안 또는 PKI 팀에서는 나쁜 습관으로 인식할 수 있지만 위험이 거의 없습니다. 이러한 인증서를 암시적으로 신뢰하는 유일한 클라이언트는 클러스터 내의 다른 구성요소입니다. 기본 와일드카드 인증서를 컨테이너 사용자 공간에서 제공한 대로 이미 CA 번들에 포함된 공용 CA에서 발행한 인증서로 교체하면 외부 클라이언트가 .apps
하위 도메인에서 실행되는 애플리케이션에 안전하게 연결할 수 있습니다.
3.1.2. 기본 수신 인증서 교체 링크 복사링크가 클립보드에 복사되었습니다!
.apps
하위 도메인에 있는 애플리케이션의 기본 수신 인증서를 교체할 수 있습니다. 인증서를 교체한 후에는 웹 콘솔과 CLI를 포함한 모든 애플리케이션에 지정된 인증서에 따라 암호화가 제공됩니다.
사전 요구 사항
-
정규화된
.apps
하위 도메인 및 해당 개인 키에 맞는 와일드카드 인증서가 있어야 합니다. 각각은 별도의 PEM 형식 파일이어야 합니다. - 개인 키는 암호화되지 않아야 합니다. 키가 암호화된 경우 OpenShift Container Platform으로 가져오기 전에 키의 암호를 해독합니다.
-
인증서에는
*.apps.<clustername>.<domain>
을 표시하는subjectAltName
확장자가 포함되어야 합니다. - 인증서 파일은 체인에 하나 이상의 인증서를 포함할 수 있습니다. 파일에는 와일드카드 인증서를 첫 번째 인증서로 나열하고, 그 다음에 다른 중간 인증서, 마지막으로 루트 CA 인증서를 나열해야 합니다.
- 루트 CA 인증서를 추가 PEM 형식 파일로 복사합니다.
-
-----END CERTIFICATE-----를
포함하는 모든 인증서가 해당 줄 뒤에 캐리지 리턴 하나로 끝나는지 확인하세요.
프로세스
와일드카드 인증서에 서명하는 데 사용되는 루트 CA 인증서만 포함하는 구성 맵을 만듭니다.
oc create configmap custom-ca \ --from-file=ca-bundle.crt=</path/to/example-ca.crt> \ -n openshift-config
$ oc create configmap custom-ca \ --from-file=ca-bundle.crt=</path/to/example-ca.crt> \
1 -n openshift-config
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
</path/to/example-ca.crt>
는 로컬 파일 시스템에서 루트 CA 인증서 파일의 경로입니다. 예를 들어,/etc/pki/ca-trust/source/anchors
.
새로 생성된 구성 맵으로 클러스터 전체 프록시 구성을 업데이트합니다.
oc patch proxy/cluster \ --type=merge \ --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
$ oc patch proxy/cluster \ --type=merge \ --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고클러스터의 신뢰할 수 있는 CA만 업데이트하는 경우 MCO가
/etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt
파일을 업데이트하고 MCC(Machine Config Controller)가 각 노드에 신뢰할 수 있는 CA 업데이트를 적용하므로 노드 재부팅이 필요하지 않습니다. 하지만 이러한 변경 사항으로 인해 MCD(Machine Config Daemon)는 kubelet 및 CRI-O와 같은 각 노드의 중요 서비스를 다시 시작합니다. 이러한 서비스 재시작으로 인해 각 노드는 서비스가 완전히 재시작될 때까지 잠시NotReady
상태로 전환됩니다.openshift-config-user-ca-bundle.crt
파일에서noproxy
와 같은 다른 매개변수를 변경하면 MCO는 클러스터의 각 노드를 재부팅합니다.와일드카드 인증서 체인과 키를 포함하는 보안을 생성합니다.
oc create secret tls <secret> \ --cert=</path/to/cert.crt> \ --key=</path/to/cert.key> \ -n openshift-ingress
$ oc create secret tls <secret> \
1 --cert=</path/to/cert.crt> \
2 --key=</path/to/cert.key> \
3 -n openshift-ingress
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새로 생성된 보안으로 Ingress Controller 구성을 업데이트합니다.
oc patch ingresscontroller.operator default \ --type=merge -p \ '{"spec":{"defaultCertificate": {"name": "<secret>"}}}' \ -n openshift-ingress-operator
$ oc patch ingresscontroller.operator default \ --type=merge -p \ '{"spec":{"defaultCertificate": {"name": "<secret>"}}}' \
1 -n openshift-ingress-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<secret>
을 이전 단계에서 보안에 사용된 이름으로 교체합니다.
중요Ingress Operator가 롤링 업데이트를 수행하도록 하려면 비밀 이름을 업데이트해야 합니다. kubelet은 볼륨 마운트의 비밀에 대한 변경 사항을 자동으로 전파하므로 비밀 내용을 업데이트해도 롤링 업데이트가 트리거되지 않습니다. 자세한 내용은 Red Hat Knowledgebase 솔루션을 참조하세요.