2.6. 서비스 메시에서 보안 사용자 정의

주의

서비스 메시 애플리케이션이 복잡한 마이크로 서비스를 사용하여 구성된 경우 Red Hat OpenShift Service Mesh를 사용하여 해당 서비스 간 통신 보안을 사용자 지정할 수 있습니다.

2.6.1. mTLS(mutual Transport Layer Security) 활성화

mTLS(mutual Transport Layer Security)은 두 당사자가 서로 인증하는 프로토콜입니다. 일부 프로토콜(IKE, SSH)에서는 기본 인증 모드이며, 다른 프로토콜(TLS)에서는 선택적입니다.

mTLS는 애플리케이션이나 서비스 코드에 대한 변경 없이 사용할 수 있습니다. TLS는 서비스 메시 인프라와 두 사이드카 프록시 사이에서 전적으로 처리됩니다.

기본적으로 Red Hat OpenShift Service Mesh가 허용 모드로 설정됩니다. 여기서 서비스 메시의 사이드카는 일반 텍스트 트래픽과 mTLS를 사용하여 암호화된 연결을 모두 허용합니다. 메시의 서비스가 메시 외부 서비스와 통신하는 경우 엄격한 mTLS가 해당 서비스 간의 통신을 중단할 수 있습니다. 워크로드를 서비스 메시로 마이그레이션하는 동안 허용 모드를 사용합니다.

2.6.1.1. 메시에서 엄격한 mTLS 활성화

워크로드가 메시 외부의 서비스와 통신하지 않고 암호화된 연결만 수락하여 통신이 중단되지 않는 경우 메시 전체에서 mTLS를 빠르게 활성화할 수 있습니다. ServiceMeshControlPlane 리소스에서 spec.istio.global.mtls.enabled를 true로 설정합니다. Operator는 필요한 리소스를 생성합니다.

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true

2.6.1.1.1. 특정 서비스의 수신 연결에 대해 사이드카 구성

정책을 생성하여 개별 서비스 또는 네임스페이스에 대해 mTLS를 구성할 수도 있습니다.

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: default
  namespace: <NAMESPACE>
spec:
  peers:
    - mtls: {}

2.6.1.2. 발신 연결에 대한 사이드카 구성

메시에서 다른 서비스로 요청을 보낼 때 mTLS를 사용하도록 서비스 메시를 구성하는 대상 규칙을 생성합니다.

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "default"
  namespace: <CONTROL_PLANE_NAMESPACE>>
spec:
  host: "*.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

2.6.1.3. 최소 및 최대 프로토콜 버전 설정

사용자 환경에 서비스 메시의 암호화된 트래픽에 대한 특정 요구 사항이 있는 경우 ServiceMeshControlPlane 리소스에 spec.security.controlPlane.tls.minProtocolVersion 또는 spec.security.controlPlane.tls.maxProtocolVersion을 설정하여 허용되는 암호화 기능을 제어할 수 있습니다. 컨트롤 플레인 리소스에 구성된 해당 값은 TLS를 통해 안전하게 통신할 때 메시 구성 요소에서 사용하는 최소 및 최대 TLS 버전을 정의합니다.

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      tls:
        minProtocolVersion: TLSv1_2
        maxProtocolVersion: TLSv1_3

기본값은 TLS_AUTO이며 TLS 버전을 지정하지 않습니다.

표 2.3. 유효한 값
값	설명
`TLS_AUTO`	default
`TLSv1_0`	TLS 버전 1.0
`TLSv1_1`	TLS 버전 1.1
`TLSv1_2`	TLS 버전 1.2
`TLSv1_3`	TLS 버전 1.3

2.6.2. 암호화 제품군 및 ECDH 곡선 구성

암호화 제품군 및 ECDH(Elliptic-curve Diffie–Hellman) 곡선은 서비스 메시를 보호하는 데 도움이 될 수 있습니다. ServiceMeshControlPlane 리소스에서 spec.istio.global.tls.cipherSuites를 사용하는 암호화 제품군과 spec.istio.global.tls.ecdhCurves를 사용하는 ECDH 곡선을 쉼표로 구분된 목록으로 정의할 수 있습니다. 이러한 속성 중 하나가 비어 있으면 기본값이 사용됩니다.

서비스 메시에서 TLS 1.2 또는 이전 버전을 사용하는 경우 cipherSuites 설정이 적용됩니다. TLS 1.3을 사용할 때는 효과가 없습니다.

우선순위에 따라 암호화 제품군을 쉼표로 구분된 목록으로 설정합니다. 예를 들어 ecdhCurves: CurveP256, CurveP384는 CurveP256을 CurveP384보다 높은 우선순위로 설정합니다.

참고

암호화 제품군을 구성할 때 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 또는 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256을 포함해야 합니다. HTTP/2 지원에는 이러한 암호화 제품군 중 하나 이상이 필요합니다.

지원되는 암호화 제품군은 다음과 같습니다.

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

지원되는 ECDH 곡선은 다음과 같습니다.

CurveP256
CurveP384
CurveP521
X25519

2.6.3. 외부 인증 기관 키 및 인증서 추가

기본적으로 Red Hat OpenShift Service Mesh는 자체 서명된 루트 인증서와 키를 생성하고 이를 사용하여 워크로드 인증서에 서명합니다. 사용자 정의 인증서 및 키를 사용하여 사용자 정의 루트 인증서로 워크로드 인증서에 서명할 수도 있습니다. 이 작업은 인증서와 키를 서비스 메시에 연결하는 예제를 보여줍니다.

사전 요구 사항

인증서를 구성하려면 상호 TLS가 활성화된 Red Hat OpenShift Service Mesh를 설치해야 합니다.
이 예제에서는 Maistra 리포지토리의 인증서를 사용합니다. 프로덕션의 경우 인증 기관의 자체 인증서를 사용합니다.
이러한 지침으로 결과를 확인하려면 Bookinfo 샘플 애플리케이션을 배포해야 합니다.

2.6.3.1. 기존 인증서 및 키 추가

기존 서명(CA) 인증서 및 키를 사용하려면 CA 인증서, 키, 루트 인증서가 포함된 신뢰 파일 체인을 생성해야 합니다. 해당 인증서 각각에 대해 다음과 같은 정확한 파일 이름을 사용해야 합니다. CA 인증서를 ca-cert.pem, 키는 ca-key.pem이라고 합니다. ca-cert.pem을 서명하는 루트 인증서는 root-cert.pem이라고 합니다. 워크로드에서 중개 인증서를 사용하는 경우 cert-chain.pem 파일에 인증서를 지정해야 합니다.

다음 단계에 따라 서비스 메시에 인증서를 추가합니다.

입력 파일 ca-cert.pem, ca-key.pem, root-cert.pem, cert-chain.pem을 포함하는 시크릿 cacert를 생성합니다.

$ oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \
    --from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \
    --from-file=<path>/cert-chain.pem

서비스 메시는 secret-mount 파일에서 인증서와 키를 읽습니다.

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
    security:
      selfSigned: false

워크로드에 새 인증서를 즉시 추가하려면 서비스 메시에서 생성한 istio.*라는 시크릿을 삭제합니다. 이 예제에서는 istio.default 입니다. 서비스 메시는 워크로드에 대한 새 인증서를 발행합니다.
```
$ oc delete secret istio.default
```

2.6.3.2. 인증서 확인

Bookinfo 샘플 애플리케이션을 사용하여 인증서가 올바르게 마운트되었는지 확인합니다. 먼저 마운트된 인증서를 검색합니다. 그런 다음 pod에 마운트된 인증서를 확인합니다.

pod 이름을 변수 RATINGSPOD에 저장합니다.

$ RATINGSPOD=`oc get pods -l app=ratings -o jsonpath='{.items[0].metadata.name}'`

다음 명령을 실행하여 프록시에 마운트된 인증서를 검색합니다.
```
$ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/root-cert.pem > /tmp/pod-root-cert.pem
```
/tmp/pod-root-cert.pem 파일에는 Pod로 전달된 루트 인증서가 포함되어 있습니다.
```
$ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/cert-chain.pem > /tmp/pod-cert-chain.pem
```
/tmp/pod-cert-chain.pem 파일에는 Pod로 전달된 워크로드 인증서와 CA 인증서가 포함되어 있습니다.

루트 인증서가 Operator가 지정한 것과 동일한지 확인합니다. <path>를 인증서 경로로 교체합니다.

$ openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txt

$ openssl x509 -in /tmp/pod-root-cert.pem -text -noout > /tmp/pod-root-cert.crt.txt

$ diff /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt

출력 대상이 비어 있을 것으로 예상됩니다.

CA 인증서가 Operator가 지정한 것과 동일한지 확인합니다. <path>를 인증서 경로로 교체합니다.

$ sed '0,/^-----END CERTIFICATE-----/d' /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-ca.pem

$ openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt

$ openssl x509 -in /tmp/pod-cert-chain-ca.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt

$ diff /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt

출력 대상이 비어 있을 것으로 예상됩니다.

루트 인증서에서 워크로드 인증서로의 인증서 체인을 확인합니다. <path>를 인증서 경로로 교체합니다.

$ head -n 21 /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-workload.pem

$ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) /tmp/pod-cert-chain-workload.pem

출력 예

/tmp/pod-cert-chain-workload.pem: OK

2.6.3.3. 인증서 제거

추가한 인증서를 제거하려면 다음 단계를 따르십시오.

시크릿 cacerts를 제거합니다.

$ oc delete secret cacerts -n istio-system

ServiceMeshControlPlane 리소스에서 자체 서명된 루트 인증서로 서비스 메시를 재배포합니다.

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
    security:
      selfSigned: true

2.6. 서비스 메시에서 보안 사용자 정의

2.6.1. mTLS(mutual Transport Layer Security) 활성화

2.6.1.1. 메시에서 엄격한 mTLS 활성화

2.6.1.1.1. 특정 서비스의 수신 연결에 대해 사이드카 구성

2.6.1.2. 발신 연결에 대한 사이드카 구성

2.6.1.3. 최소 및 최대 프로토콜 버전 설정

2.6.2. 암호화 제품군 및 ECDH 곡선 구성

2.6.3. 외부 인증 기관 키 및 인증서 추가

2.6.3.1. 기존 인증서 및 키 추가

2.6.3.2. 인증서 확인

2.6.3.3. 인증서 제거

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links