10.2. 보안 경로
보안 경로는 여러 유형의 TLS 종료를 사용하여 클라이언트에 인증서를 제공하는 기능을 제공합니다. 다음 섹션에서는 사용자 정의 인증서를 사용하여 재암호화 에지 및 패스스루 경로를 생성하는 방법을 설명합니다.
공용 끝점을 통해 Microsoft Azure에서 경로를 생성하는 경우 리소스 이름에 제한이 적용됩니다. 특정 용어를 사용하는 리소스를 생성할 수 없습니다. Azure에서 제한하는 용어 목록은 Azure 설명서의 예약된 리소스 이름 오류 해결을 참조하십시오.
10.2.1. 사용자 정의 인증서를 사용하여 재암호화 경로 생성
oc create route 명령을 사용하면 재암호화 TLS 종료와 사용자 정의 인증서로 보안 경로를 구성할 수 있습니다.
사전 요구 사항
- PEM 인코딩 파일에 인증서/키 쌍이 있고 해당 인증서가 경로 호스트에 유효해야 합니다.
- 인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
- PEM 인코딩 파일에 별도의 대상 CA 인증서가 있어야 합니다.
- 노출하려는 서비스가 있어야 합니다.
암호로 보호되는 키 파일은 지원되지 않습니다. 키 파일에서 암호를 제거하려면 다음 명령을 사용하십시오.
$ openssl rsa -in password_protected_tls.key -out tls.key
프로세스
이 절차에서는 사용자 정의 인증서를 사용하여 Route 리소스를 생성하고 TLS 종료를 재암호화합니다. 다음 예에서는 인증서/키 쌍이 현재 작업 디렉터리의 tls.crt 및 tls.key 파일에 있다고 가정합니다. Ingress 컨트롤러에서 서비스의 인증서를 신뢰하도록 하려면 대상 CA 인증서도 지정해야 합니다. 인증서 체인을 완료하는 데 필요한 경우 CA 인증서를 지정할 수도 있습니다. tls.crt, tls.key, cacert.crt, ca.crt(옵션)에 실제 경로 이름을 사용하십시오. frontend에는 노출하려는 서비스 리소스 이름을 사용합니다. www.example.com을 적절한 호스트 이름으로 바꿉니다.
재암호화 TLS 종료 및 사용자 정의 인증서를 사용하여 보안
Route리소스를 생성합니다.$ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
생성된
Route리소스는 다음과 유사합니다.보안 경로의 YAML 정의
apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend spec: host: www.example.com to: kind: Service name: frontend tls: termination: reencrypt key: |- -----BEGIN PRIVATE KEY----- [...] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- destinationCACertificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE-----자세한 옵션은
oc create route reencrypt --help를 참조하십시오.
10.2.2. 사용자 정의 인증서를 사용하여 엣지 경로 생성
oc create route 명령을 사용하면 엣지 TLS 종료와 사용자 정의 인증서로 보안 경로를 구성할 수 있습니다. 엣지 경로를 사용하면 Ingress 컨트롤러에서 트래픽을 대상 Pod로 전달하기 전에 TLS 암호화를 종료합니다. 이 경로는 Ingress 컨트롤러가 경로에 사용하는 TLS 인증서 및 키를 지정합니다.
사전 요구 사항
- PEM 인코딩 파일에 인증서/키 쌍이 있고 해당 인증서가 경로 호스트에 유효해야 합니다.
- 인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
- 노출하려는 서비스가 있어야 합니다.
암호로 보호되는 키 파일은 지원되지 않습니다. 키 파일에서 암호를 제거하려면 다음 명령을 사용하십시오.
$ openssl rsa -in password_protected_tls.key -out tls.key
프로세스
이 절차에서는 사용자 정의 인증서 및 엣지 TLS 종료를 사용하여 Route 리소스를 생성합니다. 다음 예에서는 인증서/키 쌍이 현재 작업 디렉터리의 tls.crt 및 tls.key 파일에 있다고 가정합니다. 인증서 체인을 완료하는 데 필요한 경우 CA 인증서를 지정할 수도 있습니다. tls.crt, tls.key, ca.crt(옵션)에 실제 경로 이름을 사용하십시오. frontend에는 노출하려는 서비스 이름을 사용합니다. www.example.com을 적절한 호스트 이름으로 바꿉니다.
엣지 TLS 종료 및 사용자 정의 인증서를 사용하여 보안
Route리소스를 생성합니다.$ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com
생성된
Route리소스는 다음과 유사합니다.보안 경로의 YAML 정의
apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend spec: host: www.example.com to: kind: Service name: frontend tls: termination: edge key: |- -----BEGIN PRIVATE KEY----- [...] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE-----추가 옵션은
oc create route edge --help를 참조하십시오.
10.2.3. 패스스루 라우팅 생성
oc create route 명령을 사용하면 패스스루 종료와 사용자 정의 인증서로 보안 경로를 구성할 수 있습니다. 패스스루 종료를 사용하면 암호화된 트래픽이 라우터에서 TLS 종료를 제공하지 않고 바로 대상으로 전송됩니다. 따라서 라우터에 키 또는 인증서가 필요하지 않습니다.
사전 요구 사항
- 노출하려는 서비스가 있어야 합니다.
프로세스
Route리소스를 생성합니다.$ oc create route passthrough route-passthrough-secured --service=frontend --port=8080
생성된
Route리소스는 다음과 유사합니다.패스스루 종료를 사용하는 보안 경로
apiVersion: route.openshift.io/v1 kind: Route metadata: name: route-passthrough-secured 1 spec: host: www.example.com port: targetPort: 8080 tls: termination: passthrough 2 insecureEdgeTerminationPolicy: None 3 to: kind: Service name: frontend
대상 Pod는 끝점의 트래픽에 대한 인증서를 제공해야 합니다. 현재 이 방법은 양방향 인증이라고도 하는 클라이언트 인증서도 지원할 수 있는 유일한 방법입니다.
10.2.4. 외부 관리 인증서를 사용하여 경로 생성
TLS 시크릿에서 외부 인증서로 경로를 보호하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
경로 API의 .spec.tls.externalCertificate 필드를 사용하여 타사 인증서 관리 솔루션으로 OpenShift Dedicated 경로를 구성할 수 있습니다. 시크릿을 통해 외부 관리형 TLS 인증서를 참조할 수 있으므로 수동 인증서 관리가 필요하지 않습니다. 외부 관리형 인증서를 사용하면 인증서 업데이트를 원활하게 롤아웃하는 오류를 줄일 수 있으므로 OpenShift 라우터에서 업데이트된 인증서를 즉시 제공할 수 있습니다.
이 기능은 에지 경로와 재암호화 경로에 모두 적용됩니다.
사전 요구 사항
-
RouteExternalCertificate기능 게이트를 활성화해야 합니다. -
routes/custom-host에 대한생성및업데이트권한이 있어야 합니다. -
tls.key및tls.crt키가 모두 포함된kubernetes.io/tls유형의 PEM 인코딩 형식의 유효한 인증서/키 쌍이 포함된 시크릿이 있어야 합니다. - 참조된 보안을 보안하려는 경로와 동일한 네임스페이스에 배치해야 합니다.
프로세스
다음 명령을 실행하여 라우터 서비스 계정을 읽을 수 있도록 시크릿과 동일한 네임스페이스에
역할을생성합니다.$ oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \ 1 --namespace=<current-namespace> 2
보안과 동일한 네임스페이스에
rolebinding을 생성하고 다음 명령을 실행하여 라우터 서비스 계정을 새로 생성된 역할에 바인딩합니다.$ oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace> 1- 1
- 시크릿과 경로가 모두 있는 네임스페이스를 지정합니다.
경로를정의하는 YAML 파일을 생성하고 다음 예제를 사용하여 인증서가 포함된 보안을 지정합니다.보안 경로에 대한 YAML 정의
apiVersion: route.openshift.io/v1 kind: Route metadata: name: myedge namespace: test spec: host: myedge-test.apps.example.com tls: externalCertificate: name: <secret-name> 1 termination: edge [...] [...]- 1
- 시크릿의 실제 이름을 지정합니다.
다음 명령을 실행하여
경로리소스를 생성합니다.$ oc apply -f <route.yaml> 1- 1
- 생성된 YAML 파일 이름을 지정합니다.
보안이 존재하고 인증서/키 쌍이 있는 경우 라우터는 모든 사전 요구 사항을 충족하는 경우 생성된 인증서를 제공합니다.
.spec.tls.externalCertificate 를 제공하지 않으면 라우터에서 기본 생성된 인증서를 사용합니다.
.spec.tls.externalCertificate 필드를 사용하는 경우 .spec.tls.certificate 필드 또는 .spec.tls.key 필드를 지정할 수 없습니다.
추가 리소스
- 외부 관리형 인증서가 있는 경로 문제 해결은 OpenShift Dedicated 라우터 Pod 로그에 오류가 있는지 확인하십시오. Pod 문제 수집을 참조하십시오.
