6.3. Ingress 컨트롤러 구성 매개변수
ingresscontrollers.operator.openshift.io 리소스에서 제공되는 구성 매개변수는 다음과 같습니다.
| 매개변수 | 설명 |
|---|---|
|
|
비어 있는 경우 기본값은 |
|
|
|
|
|
설정되지 않은 경우, 기본값은
대부분의 플랫폼의 경우 |
|
|
보안에는 키와 데이터, 즉 *
설정하지 않으면 와일드카드 인증서가 자동으로 생성되어 사용됩니다. 인증서는 Ingress 컨트롤러 생성된 인증서 또는 사용자 정의 인증서는 OpenShift Container Platform 내장 OAuth 서버와 자동으로 통합됩니다. |
|
|
|
|
|
|
|
|
설정하지 않으면 기본값이 사용됩니다. 참고
nodePlacement:
nodeSelector:
matchLabels:
kubernetes.io/os: linux
tolerations:
- effect: NoSchedule
operator: Exists |
|
|
설정되지 않으면, 기본값은
Ingress 컨트롤러의 최소 TLS 버전은 중요
HAProxy Ingress 컨트롤러 이미지는 TLS
또한, Ingress Operator는
OpenShift Container Platform 라우터를 사용하면 TLS_AES_128_CCM_SHA256 참고
구성된 보안 프로파일의 암호 및 최소 TLS 버전은 |
|
|
|
|
|
|
|
|
기본적으로 정책은
이러한 조정은 HTTP/1을 사용하는 경우에만 일반 텍스트, 에지 종료 및 재암호화 경로에 적용됩니다.
요청 헤더의 경우 이러한 조정은 |
|
|
|
|
|
|
|
|
캡처하려는 모든 쿠키의 경우 다음 매개변수는
예를 들면 다음과 같습니다. httpCaptureCookies:
- matchType: Exact
maxLength: 128
name: MYCOOKIE
|
|
|
httpCaptureHeaders:
request:
- maxLength: 256
name: Connection
- maxLength: 128
name: User-Agent
response:
- maxLength: 256
name: Content-Type
- maxLength: 256
name: Content-Length
|
|
|
|
모든 매개변수는 선택 사항입니다.
6.3.1. Ingress 컨트롤러 TLS 보안 프로필
TLS 보안 프로필은 서버가 서버에 연결할 때 연결 클라이언트가 사용할 수 있는 암호를 규제하는 방법을 제공합니다.
6.3.1.1. TLS 보안 프로필 이해
TLS(Transport Layer Security) 보안 프로필을 사용하여 다양한 OpenShift Container Platform 구성 요소에 필요한 TLS 암호를 정의할 수 있습니다. OpenShift Container Platform TLS 보안 프로필은 Mozilla 권장 구성을 기반으로 합니다.
각 구성 요소에 대해 다음 TLS 보안 프로필 중 하나를 지정할 수 있습니다.
| Profile | 설명 |
|---|---|
|
| 이 프로필은 레거시 클라이언트 또는 라이브러리와 함께 사용하기 위한 것입니다. 프로필은 이전 버전과의 호환성 권장 구성을 기반으로 합니다.
참고 Ingress 컨트롤러의 경우 최소 TLS 버전이 1.0에서 1.1로 변환됩니다. |
|
| 이 프로필은 대부분의 클라이언트에서 권장되는 구성입니다. Ingress 컨트롤러, kubelet 및 컨트롤 플레인의 기본 TLS 보안 프로필입니다. 프로필은 중간 호환성 권장 구성을 기반으로 합니다.
|
|
| 이 프로필은 이전 버전과의 호환성이 필요하지 않은 최신 클라이언트와 사용하기 위한 것입니다. 이 프로필은 최신 호환성 권장 구성을 기반으로 합니다.
참고
OpenShift Container Platform 4.6, 4.7, 4.8에서는 중요
현재 |
|
| 이 프로필을 사용하면 사용할 TLS 버전과 암호를 정의할 수 있습니다. 주의
참고
OpenShift Container Platform 라우터를 사용하면 Red Hat에서 배포한 OpenSSL 기본 TLS |
미리 정의된 프로파일 유형 중 하나를 사용하는 경우 유효한 프로파일 구성은 릴리스마다 변경될 수 있습니다. 예를 들어 릴리스 X.Y.Z에 배포된 중간 프로필을 사용하는 사양이 있는 경우 릴리스 X.Y.Z+1로 업그레이드하면 새 프로필 구성이 적용되어 롤아웃이 발생할 수 있습니다.
6.3.1.2. Ingress 컨트롤러의 TLS 보안 프로필 구성
Ingress 컨트롤러에 대한 TLS 보안 프로필을 구성하려면 IngressController CR(사용자 정의 리소스)을 편집하여 사전 정의된 또는 사용자 지정 TLS 보안 프로필을 지정합니다. TLS 보안 프로필이 구성되지 않은 경우 기본값은 API 서버에 설정된 TLS 보안 프로필을 기반으로 합니다.
Old TLS 보안 프로파일을 구성하는 샘플 IngressController CR
apiVersion: operator.openshift.io/v1
kind: IngressController
...
spec:
tlsSecurityProfile:
old: {}
type: Old
...
TLS 보안 프로필은 Ingress 컨트롤러의 TLS 연결에 대한 최소 TLS 버전과 TLS 암호를 정의합니다.
Status.Tls Profile 아래의 IngressController CR(사용자 정의 리소스) 및 Spec.Tls Security Profile 아래 구성된 TLS 보안 프로필에서 구성된 TLS 보안 프로필의 암호 및 최소 TLS 버전을 확인할 수 있습니다. Custom TLS 보안 프로필의 경우 특정 암호 및 최소 TLS 버전이 두 매개변수 아래에 나열됩니다.
HAProxy Ingress 컨트롤러 이미지는 TLS 1.3을 지원하지 않으며 Modern 프로파일에는 TLS 1.3이 필요하므로 이는 지원되지 않습니다. Ingress Operator는 Modern 프로파일을 Intermediate로 변환합니다.
또한, Ingress Operator는 Old 또는 Custom 프로파일의 TLS 1.0을 1.1로 변환하고 Custom 프로파일의 TLS 1.3을 1.2로 변환합니다.
사전 요구 사항
-
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
프로세스
openshift-ingress-operator프로젝트에서IngressControllerCR을 편집하여 TLS 보안 프로필을 구성합니다.$ oc edit IngressController default -n openshift-ingress-operator
spec.tlsSecurityProfile필드를 추가합니다.Custom프로필에 대한IngressControllerCR 샘플apiVersion: operator.openshift.io/v1 kind: IngressController ... spec: tlsSecurityProfile: type: Custom 1 custom: 2 ciphers: 3 - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 minTLSVersion: VersionTLS11 ...- 파일을 저장하여 변경 사항을 적용합니다.
검증
IngressControllerCR에 프로파일이 설정되어 있는지 확인합니다.$ oc describe IngressController default -n openshift-ingress-operator
출력 예
Name: default Namespace: openshift-ingress-operator Labels: <none> Annotations: <none> API Version: operator.openshift.io/v1 Kind: IngressController ... Spec: ... Tls Security Profile: Custom: Ciphers: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 Min TLS Version: VersionTLS11 Type: Custom ...
6.3.2. Ingress 컨트롤러 끝점 게시 전략
NodePortService 끝점 게시 전략
NodePortService 끝점 게시 전략에서는 Kubernetes NodePort 서비스를 사용하여 Ingress 컨트롤러를 게시합니다.
이 구성에서는 Ingress 컨트롤러를 배포하기 위해 컨테이너 네트워킹을 사용합니다. 배포를 게시하기 위해 NodePortService가 생성됩니다. 특정 노드 포트는 OpenShift Container Platform에 의해 동적으로 할당됩니다. 그러나 정적 포트 할당을 지원하기 위해 관리형 NodePortService의 노드 포트 필드에 대한 변경 사항은 유지됩니다.
그림 6.1. NodePortService 다이어그램
앞의 그래픽에서는 OpenShift Container Platform Ingress NodePort 끝점 게시 전략과 관련된 다음 개념을 보여줍니다.
- 클러스터에서 사용 가능한 모든 노드에는 외부적으로 액세스할 수 있는 자체 노드가 있습니다. 클러스터에서 실행 중인 서비스는 모든 노드에 대해 고유한 NodePort에 바인딩됩니다.
-
클라이언트가 그래픽에서
10.0.128.4IP 주소를 연결하여 다운된 노드에 연결할 때 노드 포트는 클라이언트를 서비스를 실행하는 사용 가능한 노드에 직접 연결합니다. 이 시나리오에서는 로드 밸런싱이 필요하지 않습니다. 이미지에10.0.128.4주소가 다운되고 다른 IP 주소를 대신 사용해야 합니다.
Ingress Operator는 서비스의 .spec.ports[].nodePort 필드에 대한 업데이트를 무시합니다.
기본적으로 포트는 자동으로 할당되며 통합을 위해 포트 할당에 액세스할 수 있습니다. 그러나 동적 포트에 대한 응답으로 쉽게 재구성할 수 없는 기존 인프라와 통합하기 위해 정적 포트 할당이 필요한 경우가 있습니다. 정적 노드 포트와 통합하기 위해 관리 서비스 리소스를 직접 업데이트할 수 있습니다.
자세한 내용은 NodePort에 대한 Kubernetes 서비스 설명서를 참조하십시오.
HostNetwork 끝점 게시 전략
HostNetwork 끝점 게시 전략에서는 Ingress 컨트롤러가 배포된 노드 포트에 Ingress 컨트롤러를 게시합니다.
HostNetwork 끝점 게시 전략이 있는 Ingress 컨트롤러는 노드당 하나의 pod 복제본만 가질 수 있습니다. n개의 복제본이 필요한 경우에는 해당 복제본을 예약할 수 있는 n개 이상의 노드를 사용해야 합니다. 각 pod 복제본은 예약된 노드 호스트에서 포트 80 및 443을 요청하므로 동일한 노드의 다른 pod가 해당 포트를 사용하는 경우 복제본을 노드에 예약할 수 없습니다.
