지원콘솔개발자평가판 시작연락처

1.11.4.4.2. 2.0 ServiceMeshControlPlane 구성

Red Hat OpenShift Service Mesh 버전 2.0에서 ServiceMeshControlPlane 리소스가 변경되었습니다. ServiceMeshControlPlane 리소스의 v2 버전을 생성한 후 새 기능을 활용하고 배포에 적합하게 수정합니다. ServiceMeshControlPlane 리소스를 수정할 때 Red Hat OpenShift Service Mesh 2.0의 사양 및 동작에 대해 다음과 같은 변경 사항을 고려하십시오. 또한 사용하는 기능에 대한 새로운 정보는 Red Hat OpenShift Service Mesh 2.0 제품 문서를 참조하십시오. v2 리소스는 Red Hat OpenShift Service Mesh 2.0 설치에 사용해야 합니다.

1.11.4.4.2.1. 아키텍처 변경

이전 버전에서 사용하는 아키텍처 단위는 Istiod로 교체되었습니다. 2.0에서 서비스 메시 컨트롤 플레인 구성 요소 Mixer, Pilot, Citadel, Galley, 사이드카 인젝터 기능이 단일 구성 요소인 Istiod로 결합되었습니다.

Mixer는 더 이상 컨트롤 플레인 구성 요소로 지원되지 않지만, Mixer 정책 및 Telemetry 플러그인은 이제 Istiod의 WASM 확장을 통해 지원됩니다. 레거시 Mixer 플러그인을 통합해야 하는 경우 정책 및 Telemetry에 대해 Mixer를 활성화할 수 있습니다.

SDS(Secret Discovery Service)는 Istiod에서 직접 사이드카에 인증서와 키를 배포하는 데 사용됩니다. Red Hat OpenShift Service Mesh 버전 1.1에서는 Citadel에 의해 시크릿이 생성되었으며, 이는 프록시가 클라이언트 인증서와 키를 검색하는 데 사용되었습니다.

1.11.4.4.2.2. 주석 변경

v2.0에서는 다음과 같은 주석이 더 이상 지원되지 않습니다. 이러한 주석 중 하나를 사용하는 경우 v2.0 Service Mesh Control Plane으로 이동하기 전에 워크로드를 업데이트해야 합니다.

  • sidecar.maistra.io/proxyCPULimit은 sidecar.istio.io/proxyCPULimit로 교체되었습니다. 워크로드에서 sidecar.maistra.io 주석을 사용 중인 경우 대신 동등한 sidecar.istio.io를 사용하도록 해당 워크로드를 수정해야 합니다.
  • sidecar.maistra.io/proxyMemoryLimit가 sidecar.istio.io/proxyMemoryLimit로 교체됨
  • sidecar.istio.io/discoveryAddress는 더 이상 지원되지 않습니다. 또한 기본 검색 주소는 pilot.<control_plane_namespace>.svc:15010(또는 mtls가 활성화된 경우 포트 15011)에서 istiod-<smcp_name>.<control_plane_namespace>.svc:15012로 이동했습니다.
  • 상태 포트는 더 이상 구성할 수 없으며 15021로 하드 코딩됩니다. * 사용자 정의 상태 포트(예: status.sidecar.istio.io/port )를 정의하는 경우 워크로드를 v2.0 서비스 메시 컨트롤 플레인으로 이동하기 전에 재정의를 제거해야 합니다. 상태 포트를 0 으로 설정하여 준비 상태 점검을 비활성화할 수 있습니다.
  • Kubernetes 시크릿 리소스는 더 이상 사이드카에 대한 클라이언트 인증서를 배포하는 데 사용되지 않습니다. 인증서는 이제 Istiod의 SDS 서비스를 통해 배포됩니다. 마운트된 보안을 사용하는 경우 v2.0 Service Mesh Control Plane의 워크로드에 더 오래 사용할 수 있습니다.
1.11.4.4.2.3. 동작 변경

Red Hat OpenShift Service Mesh 2.0의 일부 기능은 이전 버전과 다르게 작동합니다.

  • 게이트웨이의 준비 상태 포트는 15020에서 15021로 이동했습니다.
  • 대상 호스트 가시성에는 VirtualService 및 ServiceEntry 리소스가 포함됩니다. 사이드카 리소스를 통해 적용된 모든 제한을 포함합니다.
  • 자동 상호 TLS는 기본적으로 활성화되어 있습니다. 프록시 간 통신은 글로벌 PeerAuthentication 정책에 관계없이 mTLS를 사용하도록 자동 구성됩니다.
  • 보안 연결은 spec.security.controlPlane.mtls 설정에 관계없이 프록시가 Service Mesh Control Plane과 통신할 때 항상 사용됩니다. spec.security.controlPlane.mtls 설정은 Mixer Telemetry 또는 정책에 대한 연결을 구성할 때만 사용됩니다.
1.11.4.4.2.4. 지원되지 않는 리소스에 대한 마이그레이션 세부 정보

정책(authentication.istio.io/v1alpha1)

v2.0 Service Mesh Control Planes, PeerAuthentication 및 RequestAuthentication과 함께 사용하려면 정책 리소스를 새 리소스 유형으로 마이그레이션해야 합니다. 정책 리소스의 특정 구성에 따라 동일한 효과를 달성하기 위해 여러 리소스를 구성해야 할 수 있습니다.

상호 TLS

상호 TLS 적용은 security.istio.io/v1beta1 PeerAuthentication 리소스를 사용하여 수행됩니다. 레거시 spec.peers.mtls.mode 필드는 새로운 리소스의 spec.mtls.mode 필드에 직접 매핑됩니다. 선택 기준이 spec.targets[x].name의 서비스 이름 지정에서 spec.selector.matchLabels의 레이블 선택기로 변경되었습니다. PeerAuthentication에서 레이블은 대상 목록에 이름이 지정된 서비스의 선택기와 일치해야 합니다. 모든 포트별 설정은 spec.portLevelMtls에 매핑되어야 합니다.

인증

spec.origins 에 지정된 추가 인증 방법은 security.istio.io/v1beta1 RequestAuthentication 리소스에 매핑되어야 합니다. spec.selector.matchLabels 는 PeerAuthentication의 동일한 필드와 유사하게 구성해야 합니다. spec.origins.jwt 항목의 JWT 주체와 관련된 구성은 spec.rules 항목의 유사한 필드에 매핑됩니다.

  • 정책에 지정된 spec.origins[x].jwt.triggerRules는 하나 이상의 security.istio.io/v1beta1 AuthorizationPolicy 리소스에 매핑되어야 합니다. spec.selector.labels는 RequestAuthentication의 동일한 필드와 유사하게 구성되어야 합니다.
  • spec.origins[x].jwt.triggerRules.excludedPaths.excludedPaths 는 spec.action이 ALLOW로 설정된 AuthorizationPolicy에 매핑되고, spec.rules[x].to.operation.path 항목이 제외된 경로와 일치해야 합니다.
  • spec.origins[x].jwt.triggerRules.includedPaths는 spec.action이 ALLOW로 설정된 별도의 AuthorizationPolicy에 매핑되고, spec.rules[x].to.operation.path 항목이 제외된 경로와 일치하며, spec.rules.[x].from.source.requestPrincipals 항목이 정책 리소스의 specified spec.origins[x].jwt.issuer와 일치해야 합니다

ServiceMeshPolicy(maistra.io/v1)

ServiceMeshPolicy는 v1 리소스의 spec.istio.global.mtls.enabled 또는 v2 리소스 설정의 spec.security.dataPlane.mtls 를 통해 Service Mesh Control Plane에 대해 자동으로 구성되었습니다. v2 컨트롤 플레인의 경우 설치 중에 기능적으로 동일한 PeerAuthentication 리소스가 생성됩니다. 이 기능은 Red Hat OpenShift Service Mesh 버전 2.0에서 더 이상 사용되지 않습니다.

RbacConfig, ServiceRole, ServiceRoleBinding (rbac.istio.io/v1alpha1)

이러한 리소스는 security.istio.io/v1beta1 AuthorizationPolicy 리소스로 교체되었습니다.

RbacConfig 동작을 모방하려면 RbacConfig에 지정된 spec.mode에 따라 설정이 달라지는 기본 AuthorizationPolicy를 작성해야 합니다.

  • spec.mode가 OFF로 설정되면 AuthorizationPolicy가 요청에 적용되지 않는 한 기본 정책은 ALLOW이므로 리소스가 필요하지 않습니다.
  • spec.mode가 ON으로 설정된 경우 spec: {}를 설정합니다. 메시의 모든 서비스에 대해 AuthorizationPolicy 정책을 생성해야 합니다.
  • spec.mode가 ON_WITH_INCLUSION으로 설정되며, 포함된 각각의 네임스페이스에 spec: {}을 사용하여 AuthorizationPolicy를 생성해야 합니다. 개별 서비스 포함은 AuthorizationPolicy에서 지원되지 않습니다. 그러나 서비스의 워크로드에 적용되는 AuthorizationPolicy가 생성되면 명시적으로 허용되지 않는 다른 모든 요청이 거부됩니다.
  • spec.mode가 ON_WITH_EXCLUSION으로 설정된 경우 AuthorizationPolicy에서 지원되지 않습니다. 글로벌 DENY 정책을 생성할 수 있지만, 네임스페이스 또는 워크로드에 적용할 수 있는 허용된 정책이 없기 때문에 메시의 모든 워크로드에 대해 AuthorizationPolicy를 생성해야 합니다.

AuthorizationPolicy에는 ServiceRoleBinding이 제공하는 기능과 유사한 구성이 적용되는 선택기와 ServiceRole이 제공하는 기능과 유사하며 적용되어야 하는 규칙에 대한 구성이 모두 포함됩니다.

ServiceMeshRbacConfig (maistra.io/v1)

이 리소스는 Service Mesh Control Plane의 네임스페이스에서 빈 spec.selector가 있는 security.istio.io/v1beta1 AuthorizationPolicy 리소스를 사용하여 교체됩니다. 이 정책은 메시의 모든 워크로드에 적용되는 기본 권한 부여 정책이 됩니다. 특정 마이그레이션 세부 사항은 위의 RbacConfig를 참조하십시오.

1.11.4.4.2.5. Mixer 플러그인

Mixer 구성 요소는 버전 2.0에서 기본적으로 비활성화되어 있습니다. 워크로드에 Mixer 플러그인을 사용하는 경우 Mixer 구성 요소를 포함하도록 버전 2.0 ServiceMeshControlPlane을 구성해야 합니다.

Mixer 정책 구성 요소를 활성화하려면 ServiceMeshControlPlane에 다음 스니펫을 추가합니다. 

spec:
  policy:
    type: Mixer

Mixer telemetry 구성 요소를 활성화하려면 ServiceMeshControlPlane에 다음 스니펫을 추가합니다. 

spec:
  telemetry:
    type: Mixer

또한 레거시 mixer 플러그인은 WASM으로 마이그레이션하고 새로운 ServiceMeshExtension(maistra.io/v1alpha1) 사용자 정의 리소스를 사용하여 통합할 수 있습니다.

업스트림 Istio 배포에 포함된 내장 WASM 필터는 Red Hat OpenShift Service Mesh 2.0에서 사용할 수 없습니다.

1.11.4.4.2.6. 상호 TLS 변경

워크로드별 PeerAuthentication 정책과 함께 mTLS를 사용할 때 워크로드 정책이 네임스페이스/글로벌 정책과 다를 경우 트래픽을 허용하려면 상응하는 DestinationRule이 필요합니다.

자동 mTLS는 기본적으로 활성화되어 있지만 ServiceMeshControlPlane 리소스에서 spec.security.dataPlane.automtls를 false로 설정하여 비활성화할 수 있습니다. 자동 mTLS를 비활성화할 때 서비스 간 적절한 통신을 위해 DestinationRules가 필요할 수 있습니다. 예를 들어, 하나의 네임스페이스에 대해 PeerAuthentication을 STRICT으로 설정하면 DestinationRule이 네임스페이스의 서비스에 TLS 모드를 구성하지 않는 한 다른 네임스페이스의 서비스에 액세스하지 못할 수 있습니다.

mTLS에 대한 자세한 내용은 mTLS(mutual Transport Layer Security) 활성화를 참조하십시오.

1.11.4.4.2.6.1. 기타 mTLS 예

mTLS 비활성화: bookinfo 샘플 애플리케이션의 productpage 서비스의 경우, Red Hat OpenShift Service Mesh v1.1에 대해 다음과 같은 방식으로 정책 리소스를 구성했습니다.

정책 리소스 예

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  targets:
  - name: productpage

mTLS 비활성화: bookinfo 샘플 애플리케이션의 productpage 서비스의 경우, 다음 예제를 사용하여 Red Hat OpenShift Service Mesh v2.0에 PeerAuthentication 리소스를 구성합니다.

PeerAuthentication 리소스 예

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-disable
  namespace: <namespace>
spec:
  mtls:
    mode: DISABLE
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage

mTLS 활성화: bookinfo 샘플 애플리케이션에서 productpage 서비스에 대한 JWT 인증의 경우, Red Hat OpenShift Service Mesh v1.1에 대해 다음과 같은 방식으로 정책 리소스를 구성했습니다.

정책 리소스 예

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  targets:
  - name: productpage
    ports:
    - number: 9000
  peers:
  - mtls:
  origins:
  - jwt:
      issuer: "https://securetoken.google.com"
      audiences:
      - "productpage"
      jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
      jwtHeaders:
      - "x-goog-iap-jwt-assertion"
      triggerRules:
      - excludedPaths:
        - exact: /health_check
  principalBinding: USE_ORIGIN

mTLS 활성화: bookinfo 샘플 애플리케이션에서 productpage 서비스에 대한 JWT 인증의 경우, 다음 예제를 사용하여 Red Hat OpenShift Service Mesh v2.0에 PeerAuthentication 리소스를 구성합니다.

PeerAuthentication 리소스 예

#require mtls for productpage:9000
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  portLevelMtls:
    9000:
      mode: STRICT
---
#JWT authentication for productpage
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  jwtRules:
  - issuer: "https://securetoken.google.com"
    audiences:
    - "productpage"
    jwksUri: "https://www.googleapis.com/oauth2/v1/certs"
    fromHeaders:
    - name: "x-goog-iap-jwt-assertion"
---
#Require JWT token to access product page service from
#any client to all paths except /health_check
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-mTLS-with-JWT
  namespace: <namespace>
spec:
  action: ALLOW
  selector:
    matchLabels:
      # this should match the selector for the "productpage" service
      app: productpage
  rules:
  - to: # require JWT token to access all other paths
      - operation:
          notPaths:
          - /health_check
    from:
      - source:
          # if using principalBinding: USE_PEER in the Policy,
          # then use principals, e.g.
          # principals:
          # - “*”
          requestPrincipals:
          - “*”
  - to: # no JWT token required to access health_check
      - operation:
          paths:
          - /health_check

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.