검색

2.13. 보안

download PDF

서비스 메시 애플리케이션이 복잡한 마이크로 서비스를 사용하여 구성된 경우 Red Hat OpenShift Service Mesh를 사용하여 해당 서비스 간 통신 보안을 사용자 지정할 수 있습니다. 서비스 메시의 트래픽 관리 기능과 함께 OpenShift Container Platform의 인프라는 애플리케이션의 복잡성을 관리하고 마이크로서비스를 보호하는데 도움이 됩니다.

사전 준비 사항

프로젝트가 있는 경우 ServiceMeshMemberRoll 리소스에 프로젝트를 추가합니다.

프로젝트가 없는 경우 Bookinfo 샘플 애플리케이션을 설치하고 ServiceMeshMemberRoll 리소스에 추가합니다. 샘플 애플리케이션은 보안 개념을 설명하는 데 도움이 됩니다.

2.13.1. mTLS(mutual Transport Layer Security) 정보

mTLS(mutual Transport Layer Security)는 두 당사자가 서로 인증할 수 있는 프로토콜입니다. 일부 프로토콜(IKE, SSH)에서는 기본 인증 모드이며, 다른 프로토콜(TLS)에서는 선택적입니다. 애플리케이션 또는 서비스 코드를 변경하지 않고 mTLS를 사용할 수 있습니다. TLS는 서비스 메시 인프라와 두 사이드카 프록시 사이에서 전적으로 처리됩니다.

기본적으로 Red Hat OpenShift Service Mesh의 mTLS가 활성화되고 허용 모드로 설정됩니다. 여기서 서비스 메시의 사이드카는 일반 텍스트 트래픽과 mTLS를 사용하여 암호화된 연결을 모두 허용합니다. 엄격한 mTLS를 사용하도록 구성된 메시의 서비스가 메시 외부의 서비스와 통신하는 경우 엄격한 mTLS가 클라이언트 및 서버가 서로를 확인할 수 있어야 하므로 해당 서비스 간에 통신이 중단될 수 있습니다. 워크로드를 서비스 메시로 마이그레이션하는 동안 허용 모드를 사용합니다. 그러면 메시, 네임스페이스 또는 애플리케이션 전반에서 엄격한 mTLS를 활성화할 수 있습니다.

서비스 메시 컨트롤 플레인 수준에서 메시 전체에 mTLS를 활성화하면 애플리케이션 및 워크로드를 다시 작성하지 않고도 서비스 메시의 모든 트래픽을 보호할 수 있습니다. ServiceMeshControlPlane 리소스의 데이터 플레인 수준에서 메시의 네임스페이스를 보호할 수 있습니다. 트래픽 암호화 연결을 사용자 지정하려면 PeerAuthenticationDestinationRule 리소스를 사용하여 애플리케이션 수준에서 네임스페이스를 구성합니다.

2.13.1.1. 서비스 메시에서 엄격한 mTLS 활성화

워크로드가 외부 서비스와 통신하지 않으면 통신 중단 없이 메시 전체에서 mTLS를 빠르게 활성화할 수 있습니다. ServiceMeshControlPlane 리소스에서 spec.security.dataPlane.mtlstrue로 설정하여 활성화할 수 있습니다. Operator는 필요한 리소스를 생성합니다.

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  version: v2.6
  security:
    dataPlane:
      mtls: true

또한 OpenShift Container Platform 웹 콘솔을 사용하여 mTLS를 활성화할 수 있습니다.

프로세스

  1. 웹 콘솔에 로그인합니다.
  2. 프로젝트 메뉴를 클릭하고 Service Mesh Control Plane을 설치한 프로젝트(예: istio-system )를 선택합니다.
  3. Operators 설치된 Operators를 클릭합니다.
  4. 제공된 API에서 Service Mesh Control Plane을 클릭합니다.
  5. ServiceMeshControlPlane 리소스의 이름(예: production)을 클릭합니다.
  6. 세부 정보 페이지에서 데이터 플레인 보안보안 섹션에서 토글을 클릭합니다.
2.13.1.1.1. 특정 서비스의 수신 연결에 대해 사이드카 구성

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

프로세스

  1. 다음 예제를 사용하여 YAML 파일을 생성합니다.

    PeerAuthentication 정책 예 policy.yaml

    apiVersion: security.istio.io/v1beta1
    kind: PeerAuthentication
    metadata:
      name: default
      namespace: <namespace>
    spec:
      mtls:
        mode: STRICT

    1. <namespace>를 서비스가 있는 네임스페이스로 바꿉니다.
  2. 다음 명령을 실행하여 서비스가 있는 네임스페이스에 리소스를 생성합니다. 방금 생성한 정책 리소스의 namespace 필드와 일치해야 합니다.

    $ oc create -n <namespace> -f <policy.yaml>
참고

자동 mTLS를 사용하지 않고 PeerAuthentication을 STRICT으로 설정하는 경우 서비스에 대한 DestinationRule 리소스를 생성해야 합니다.

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

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

프로세스

  1. 다음 예제를 사용하여 YAML 파일을 생성합니다.

    DestinationRule 예제 destination-rule.yaml

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

    1. <namespace>를 서비스가 있는 네임스페이스로 바꿉니다.
  2. 다음 명령을 실행하여 서비스가 있는 네임스페이스에 리소스를 생성합니다. 방금 생성한 DestinationRule 리소스의 namespace 필드와 일치해야 합니다.

    $ oc create -n <namespace> -f <destination-rule.yaml>
2.13.1.1.3. 최소 및 최대 프로토콜 버전 설정

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

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

표 2.5. 유효한 값
설명

TLS_AUTO

default

TLSv1_0

TLS 버전 1.0

TLSv1_1

TLS 버전 1.1

TLSv1_2

TLS 버전 1.2

TLSv1_3

TLS 버전 1.3

프로세스

  1. 웹 콘솔에 로그인합니다.
  2. 프로젝트 메뉴를 클릭하고 Service Mesh Control Plane을 설치한 프로젝트(예: istio-system )를 선택합니다.
  3. Operators 설치된 Operators를 클릭합니다.
  4. 제공된 API에서 Service Mesh Control Plane을 클릭합니다.
  5. ServiceMeshControlPlane 리소스의 이름(예: production)을 클릭합니다.
  6. YAML 탭을 클릭합니다.
  7. YAML 편집기에 다음 코드 조각을 삽입합니다. minProtocolVersion의 값을 TLS 버전 값으로 바꿉니다. 이 예에서 최소 TLS 버전은 TLSv1_2로 설정됩니다.

    ServiceMeshControlPlane 스니펫

    kind: ServiceMeshControlPlane
    spec:
      security:
        controlPlane:
          tls:
            minProtocolVersion: TLSv1_2

  8. 저장을 클릭합니다.
  9. 새로 고침을 클릭하여 변경 사항이 올바르게 업데이트되었는지 확인합니다.

2.13.1.2. Kiali를 사용하여 암호화 검증

Kiali 콘솔은 애플리케이션, 서비스 및 워크로드에 mTLS 암호화가 활성화되어 있는지 확인하는 여러 가지 방법을 제공합니다.

그림 2.5. 마스트 헤드 아이콘 메시 전체 mTLS 활성화

mTLS 활성화

마스트 헤드 오른쪽에는 메시가 전체 서비스 메시에 대해 엄격하게 활성화된 mTLS가 있는 경우 Kiali는 잠금 아이콘을 표시합니다. 즉, 메시의 모든 통신에서 mTLS를 사용합니다.

그림 2.6. 마스트 헤드 아이콘 메시 전체 mTLS가 부분적으로 활성화됨

mTLS 부분적으로 활성화됨

메시가 PERMISSIVE 모드로 구성되거나 메시 전체 mTLS 구성에 오류가 있을 때 Kiali는 hollow 잠금 아이콘을 표시합니다.

그림 2.7. 보안 배지

보안 배지

그래프 페이지에는 mTLS가 활성화되었음을 나타내는 그래프 에지에 보안 배지를 표시하는 옵션이 있습니다. 그래프에서 보안 배지를 활성화하려면 디스플레이 메뉴에서 Show Badges 아래의 Security 확인란을 선택합니다. 에지에 잠금 아이콘이 표시되면 mTLS가 활성화된 하나 이상의 요청이 있음을 의미합니다. mTLS 및 non-mTLS 요청이 모두 있는 경우 side-panel은 mTLS를 사용하는 요청의 백분율을 표시합니다.

애플리케이션 세부 정보 개요 페이지에는 mTLS가 활성화된 하나 이상의 요청이 있는 그래프 에지에 보안 아이콘이 표시됩니다.

워크로드 세부 정보 개요 페이지에는 mTLS가 활성화된 하나 이상의 요청이 있는 그래프 에지에 보안 아이콘이 표시됩니다.

서비스 세부 정보 개요 페이지에는 mTLS가 활성화된 하나 이상의 요청이 있는 그래프 에지에 보안 아이콘이 표시됩니다. 또한 Kiali는 mTLS용으로 구성된 포트 옆에 네트워크 섹션에 잠금 아이콘을 표시합니다.

2.13.2. 역할 기반 액세스 제어(RBAC) 구성

RBAC(역할 기반 액세스 제어) 오브젝트에 따라 사용자 또는 서비스가 프로젝트 내에서 지정된 작업을 수행할 수 있는지가 결정됩니다. 메시의 워크로드에 대해 메시, 네임스페이스, 워크로드 전체 액세스 제어를 정의할 수 있습니다.

RBAC를 구성하려면 액세스를 구성하는 네임스페이스에 AuthorizationPolicy 리소스를 생성합니다. 메시 전체 액세스를 구성하는 경우 Service Mesh Control Plane을 설치한 프로젝트(예: istio-system )를 사용합니다.

예를 들어 RBAC를 사용하면 다음과 같은 정책을 생성할 수 있습니다.

  • 프로젝트 내 통신을 구성합니다.
  • 기본 네임스페이스의 모든 워크로드에 대한 전체 액세스를 허용하거나 거부합니다.
  • 수신 게이트웨이 액세스를 허용 또는 거부합니다.
  • 액세스 하려면 토큰이 필요합니다.

권한 부여 정책에는 선택기, 작업 및 규칙 목록이 포함됩니다.

  • selector 필드는 정책의 대상을 지정합니다.
  • action 필드는 요청을 허용하거나 거부할지 여부를 지정합니다.
  • rules 필드는 작업을 트리거할 시기를 지정합니다.

    • from 필드는 요청 원본에 대한 제약 조건을 지정합니다.
    • to 필드는 요청 대상 및 매개변수에 대한 제약 조건을 지정합니다.
    • when 필드는 규칙을 적용하기 위한 추가 조건을 지정합니다.

프로세스

  1. AuthorizationPolicy 리소스를 생성합니다. 다음 예제는 IP 주소가 수신 게이트웨이에 액세스하는 것을 거부하도록 ingress-policy AuthorizationPolicy를 업데이트하는 리소스를 보여줍니다.

    apiVersion: security.istio.io/v1beta1
    kind: AuthorizationPolicy
    metadata:
      name: ingress-policy
      namespace: istio-system
    spec:
      selector:
        matchLabels:
          app: istio-ingressgateway
      action: DENY
      rules:
      - from:
        - source:
            ipBlocks: ["1.2.3.4"]
  2. 리소스를 작성한 후 다음 명령어를 실행하여 네임스페이스에 리소스를 만듭니다. 네임스페이스는 AuthorizationPolicy 리소스의 metadata.namespace 필드와 일치해야 합니다.

    $ oc create -n istio-system -f <filename>

다음 단계

다른 일반적인 구성에 대해서는 다음 예제를 고려하십시오.

2.13.2.1. 프로젝트 내 통신 구성

AuthorizationPolicy 를 사용하여 메시의 메시 또는 서비스와 통신하는 트래픽을 허용하거나 거부하도록 Service Mesh Control Plane을 구성할 수 있습니다.

2.13.2.1.1. 네임스페이스 외부 서비스에 대한 액세스 제한

다음 AuthorizationPolicy 리소스 예제를 사용하여 info 네임스페이스에 없는 소스의 요청을 거부할 수 있습니다.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin-deny
 namespace: info
spec:
 selector:
   matchLabels:
     app: httpbin
     version: v1
 action: DENY
 rules:
 - from:
   - source:
       notNamespaces: ["info"]
2.13.2.1.2. 권한 부여 모두 허용 및 권한 부여 모두 거부(기본) 정책 만들기

다음 예제에서는 info 네임스페이스의 모든 워크로드에 대한 전체 액세스 권한을 허용하는 허용 권한 부여 정책을 보여줍니다.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-all
  namespace: info
spec:
  action: ALLOW
  rules:
  - {}

다음 예제에서는 info 네임스페이스의 모든 워크로드에 대한 액세스를 거부하는 정책을 보여줍니다.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-all
  namespace: info
spec:
  {}

2.13.2.2. 수신 게이트웨이에 대한 액세스 허용 또는 거부

IP 주소를 기반으로 허용 또는 거부 목록을 추가하도록 권한 부여 정책을 설정할 수 있습니다.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: ingress-policy
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  action: ALLOW
  rules:
  - from:
    - source:
       ipBlocks: ["1.2.3.4", "5.6.7.0/24"]

2.13.2.3. JSON 웹 토큰으로 액세스 제한

JSON 웹 토큰(JWT)으로 메시에 액세스하는 항목을 제한할 수 있습니다. 인증 후 사용자 또는 서비스는 해당 토큰과 연결된 경로, 서비스에 액세스할 수 있습니다.

워크로드에서 지원하는 인증 방법을 정의하는 RequestAuthentication 리소스를 생성합니다. 다음 예제에서는 http://localhost:8080/auth/realms/master에서 발행한 JWT를 수락합니다.

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: "jwt-example"
  namespace: info
spec:
  selector:
    matchLabels:
      app: httpbin
  jwtRules:
  - issuer: "http://localhost:8080/auth/realms/master"
    jwksUri: "http://keycloak.default.svc:8080/auth/realms/master/protocol/openid-connect/certs"

그런 다음, 동일한 네임스페이스에 AuthorizationPolicy 리소스를 생성하여, 사용자가 생성한 RequestAuthentication 리소스와 함께 작업할 수 있습니다. 다음 예제에서는 httpbin 워크로드에 요청을 보낼 때 Authorization 헤더에 JWT가 있어야 합니다.

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "frontend-ingress"
  namespace: info
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

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

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

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

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

참고

암호화 제품군을 구성할 때 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.13.4. JSON 웹 키 세트 확인자 인증 기관 구성

ServiceMeshControlPlane (SMCP) 사양에서 자체 JSON 웹 키 세트(JWKS) 확인자 인증 기관(CA)을 구성할 수 있습니다.

프로세스

  1. ServiceMeshControlPlane 사양 파일을 편집합니다.

    $ oc edit smcp <smcp-name>
  2. 다음 예와 같이 ServiceMeshControlPlane 사양에서 mtls 필드 값을 true 로 설정하여 데이터 플레인의 mtls 를 활성화합니다.

    spec:
      security:
        dataPlane:
            mtls: true # enable mtls for data plane
        # JWKSResolver extra CA
        # PEM-encoded certificate content to trust an additional CA
        jwksResolverCA: |
            -----BEGIN CERTIFICATE-----
            [...]
            [...]
            -----END CERTIFICATE-----
    ...
  3. 변경 사항을 저장합니다. OpenShift Container Platform에서 자동으로 적용합니다.

pilot-jwks-cacerts-<SMCP name >과 같은 ConfigMap 은 CA .pem 데이터를 사용하여 생성됩니다.

ConfigMap pilot-jwks-cacerts-<SMCP name>의 예

kind: ConfigMap
apiVersion: v1
data:
  extra.pem: |
      -----BEGIN CERTIFICATE-----
      [...]
      [...]
      -----END CERTIFICATE-----

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

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

사전 요구 사항

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

2.13.5.1. 기존 인증서 및 키 추가

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

  1. Maistra 리포지토리에서 로컬로 예제 인증서를 저장하고 &lt ;path& gt;를 인증서 경로로 바꿉니다.
  2. 입력 파일 ca-cert.pem,ca-key.pem,root-cert.pemcert-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
  3. ServiceMeshControlPlane 리소스에서 spec.security.dataPlane.mtls truetrue 로 설정하고 다음 예와 같이 certificateAuthority 필드를 구성합니다. 기본 rootCADir/etc/cacerts입니다. 키와 인증서가 기본 위치에 마운트된 경우 privateKey를 설정할 필요가 없습니다. 서비스 메시는 secret-mount 파일에서 인증서와 키를 읽습니다.

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
        dataPlane:
          mtls: true
        certificateAuthority:
          type: Istiod
          istiod:
            type: PrivateKey
            privateKey:
              rootCADir: /etc/cacerts
  4. cacert 시크릿을 생성/변경/제거한 후 Service Mesh Control Plane istiod게이트웨이 Pod를 다시 시작해야 변경 사항이 적용됩니다. 다음 명령을 사용하여 Pod를 다시 시작합니다.

    $ oc -n istio-system delete pods -l 'app in (istiod,istio-ingressgateway, istio-egressgateway)'

    Operator는 삭제 후 Pod를 자동으로 다시 생성합니다.

  5. 사이드카 프록시가 시크릿 변경 사항을 선택하도록 info 애플리케이션 pod를 다시 시작합니다. 다음 명령을 사용하여 Pod를 다시 시작합니다.

    $ oc -n info delete pods --all

    출력은 다음과 유사합니다.

    pod "details-v1-6cd699df8c-j54nh" deleted
    pod "productpage-v1-5ddcb4b84f-mtmf2" deleted
    pod "ratings-v1-bdbcc68bc-kmng4" deleted
    pod "reviews-v1-754ddd7b6f-lqhsv" deleted
    pod "reviews-v2-675679877f-q67r2" deleted
    pod "reviews-v3-79d7549c7-c2gjs" deleted
  6. 다음 명령을 사용하여 Pod가 생성되고 준비되었는지 확인합니다.

    $ oc get pods -n info

2.13.5.2. 인증서 확인

Bookinfo 샘플 애플리케이션을 사용하여 CA에 연결된 인증서에서 워크로드 인증서를 서명하는지 확인합니다. 이 프로세스에서는 openssl 을 시스템에 설치해야 합니다.

  1. 정보 워크로드에서 인증서를 추출하려면 다음 명령을 사용합니다.

    $ sleep 60
    $ oc -n info exec "$(oc -n bookinfo get pod -l app=productpage -o jsonpath={.items..metadata.name})" -c istio-proxy -- openssl s_client -showcerts -connect details:9080 > bookinfo-proxy-cert.txt
    $ sed -n '/-----BEGIN CERTIFICATE-----/{:start /-----END CERTIFICATE-----/!{N;b start};/.*/p}' info-proxy-cert.txt > certs.pem
    $ awk 'BEGIN {counter=0;} /BEGIN CERT/{counter++} { print > "proxy-cert-" counter ".pem"}' < certs.pem

    명령을 실행하면 작업 디렉터리에 proxy-cert-1.pem,proxy-cert-2.pemproxy-cert-3.pem 이라는 세 개의 파일이 있어야 합니다.

  2. 루트 인증서가 관리자가 지정한 것과 같은지 확인합니다. <path>를 인증서 경로로 교체합니다.

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

    터미널 창에서 다음 구문을 실행합니다.

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

    터미널 창에서 다음 구문을 실행하여 인증서를 비교합니다.

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

    다음 결과가 표시됩니다. 파일 /tmp/root-cert.crt.txt 및 /tmp/pod-root-cert.crt.txt는 동일합니다.

  3. CA 인증서가 관리자가 지정한 것과 같은지 확인합니다. <path>를 인증서 경로로 교체합니다.

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

    터미널 창에서 다음 구문을 실행합니다.

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

    터미널 창에서 다음 구문을 실행하여 인증서를 비교합니다.

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

    다음 결과가 표시됩니다. 파일 /tmp/ca-cert.crt.txt 및 /tmp/pod-cert-chain-ca.crt.txt는 동일합니다.

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

    $ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) ./proxy-cert-1.pem

    다음 결과가 표시됩니다. ./proxy-cert-1.pem: OK

2.13.5.3. 인증서 제거

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

  1. 시크릿 cacerts를 제거합니다. 이 예에서 istio-system 은 Service Mesh Control Plane 프로젝트의 이름입니다.

    $ oc delete secret cacerts -n istio-system
  2. ServiceMeshControlPlane 리소스에서 자체 서명된 루트 인증서로 서비스 메시를 재배포합니다.

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    spec:
      security:
        dataPlane:
          mtls: true

2.13.6. cert-manager 및 istio-csr와 서비스 메시 통합 정보

cert-manager 툴은 Kubernetes에서 X.509 인증서 관리를 위한 솔루션입니다. Vault, Google Cloud Certificate Authority Service, Let's Encrypt 및 기타 공급자와 같은 개인 또는 공개 키 인프라(PKI)와 애플리케이션을 통합하는 통합 API를 제공합니다.

cert-manager 툴은 만료되기 전에 구성된 시간에 인증서를 갱신하여 인증서가 유효하고 최신 상태인지 확인합니다.

Istio 사용자의 경우 cert-manager는 Istio 프록시에서 CSR(인증서 서명 요청)을 처리하는 CA(인증 기관) 서버인 istio-csr 와의 통합을 제공합니다. 그런 다음 서버는 CSR을 구성된 CA 서버로 전달하는 cert-manager에 서명을 위임합니다.

참고

Red Hat은 istio-csr 및 cert-manager와의 통합을 지원합니다. Red Hat은 istio-csr 또는 커뮤니티 cert-manager 구성 요소에 대한 직접 지원을 제공하지 않습니다. 여기에 표시된 커뮤니티 cert-manager를 사용하는 것은 데모 목적으로만 사용됩니다.

사전 요구 사항

  • cert-manager 버전 중 하나:

    • cert-manager Operator for Red Hat OpenShift 1.10 이상
    • 커뮤니티 cert-manager Operator 1.11 이상
    • cert-manager 1.11 이상
  • OpenShift Service Mesh Operator 2.4 이상
  • Istio-csr 0.6.0 이상
참고

istio-csr 서버가jetstack/cert-manager-istio-csr Helm 차트와 함께 설치된 경우 모든 네임스페이스에 구성 맵을 생성하지 않으려면 istio-csr.yaml 파일에서 app.controller.configmapNamespaceSelector: "maistra.io/member-of: <istio-namespace>" 설정을 사용합니다.

2.13.6.1. cert-manager 설치

cert-manager 툴을 설치하여 TLS 인증서의 라이프사이클을 관리하고 유효하고 최신 상태인지 확인할 수 있습니다. 환경에서 Istio를 실행하는 경우 Istio 프록시에서 CSR(인증서 서명 요청)을 처리하는 istio-csr 인증 기관(CA) 서버를 설치할 수도 있습니다. istio-csr CA는 구성된 CA에 위임하는 cert-manager 툴에 서명을 위임합니다.

프로세스

  1. 루트 클러스터 발행자를 생성합니다.

    1. 다음 예와 같이 cluster-issuer 오브젝트를 생성합니다.

      예: cluster-issuer.yaml

      apiVersion: cert-manager.io/v1
      kind: Issuer
      metadata:
        name: selfsigned-root-issuer
        namespace: cert-manager
      spec:
        selfSigned: {}
      ---
      apiVersion: cert-manager.io/v1
      kind: Certificate
      metadata:
        name: root-ca
        namespace: cert-manager
      spec:
        isCA: true
        duration: 21600h # 900d
        secretName: root-ca
        commonName: root-ca.my-company.net
        subject:
          organizations:
          - my-company.net
        issuerRef:
          name: selfsigned-root-issuer
          kind: Issuer
          group: cert-manager.io
      ---
      apiVersion: cert-manager.io/v1
      kind: ClusterIssuer
      metadata:
        name: root-ca
      spec:
        ca:
          secretName: root-ca

      참고

      root-ca 는 클러스터 발행자이므로 selfsigned-root-issuer 발행자 및 root-ca 인증서의 네임스페이스가 cert-manager 이므로 cert-manager는 자체 네임스페이스에서 참조된 시크릿을 찾습니다. Red Hat OpenShift용 cert-manager Operator의 경우 네임스페이스를 cert-manager라고 합니다.

    2. 다음 명령을 사용하여 오브젝트를 생성합니다.

      $ oc apply -f cluster-issuer.yaml
    3. 다음 예와 같이 istio-ca 오브젝트를 생성합니다.

      예: istio-ca.yaml

      apiVersion: cert-manager.io/v1
      kind: Certificate
      metadata:
        name: istio-ca
        namespace: istio-system
      spec:
        isCA: true
        duration: 21600h
        secretName: istio-ca
        commonName: istio-ca.my-company.net
        subject:
          organizations:
          - my-company.net
        issuerRef:
          name: root-ca
          kind: ClusterIssuer
          group: cert-manager.io
      ---
      apiVersion: cert-manager.io/v1
      kind: Issuer
      metadata:
        name: istio-ca
        namespace: istio-system
      spec:
        ca:
          secretName: istio-ca

    4. 다음 명령을 사용하여 오브젝트를 생성합니다.

      $ oc apply -n istio-system -f istio-ca.yaml
  2. istio-csr 설치 :

    $ helm install istio-csr jetstack/cert-manager-istio-csr \
        -n istio-system \
        -f deploy/examples/cert-manager/istio-csr/istio-csr.yaml

    예: istio-csr.yaml

    replicaCount: 2
    
    image:
      repository: quay.io/jetstack/cert-manager-istio-csr
      tag: v0.6.0
      pullSecretName: ""
    
    app:
      certmanager:
        namespace: istio-system
        issuer:
          group: cert-manager.io
          kind: Issuer
          name: istio-ca
    
      controller:
        configmapNamespaceSelector: "maistra.io/member-of=istio-system"
        leaderElectionNamespace: istio-system
    
      istio:
        namespace: istio-system
        revisions: ["basic"]
    
      server:
        maxCertificateDuration: 5m
    
      tls:
        certificateDNSNames:
        # This DNS name must be set in the SMCP spec.security.certificateAuthority.cert-manager.address
        - cert-manager-istio-csr.istio-system.svc

  3. SMCP를 배포합니다.

    $ oc apply -f mesh.yaml -n istio-system

    예: mesh.yaml

    apiVersion: maistra.io/v2
    kind: ServiceMeshControlPlane
    metadata:
      name: basic
    spec:
      addons:
        grafana:
          enabled: false
        kiali:
          enabled: false
        prometheus:
          enabled: false
      proxy:
        accessLogging:
          file:
            name: /dev/stdout
      security:
        certificateAuthority:
          cert-manager:
            address: cert-manager-istio-csr.istio-system.svc:443
          type: cert-manager
        dataPlane:
          mtls: true
        identity:
          type: ThirdParty
      tracing:
        type: None
    ---
    apiVersion: maistra.io/v1
    kind: ServiceMeshMemberRoll
    metadata:
      name: default
    spec:
      members:
      - httpbin
      - sleep

참고

security.certificateAuthority.type: cert-manager 가 구성된 경우 security.identity.type: ThirdParty를 설정해야 합니다.

검증

샘플 httpbin 서비스 및 sleep 앱을 사용하여 수신 게이트웨이의 mTLS 트래픽을 확인하고 cert-manager 툴이 설치되었는지 확인합니다.

  1. HTTP 및 절전 앱을 배포합니다.

    $ oc new-project <namespace>
    $ oc apply -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin.yaml
    $ oc apply -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/sleep/sleep.yaml
  2. sleep 에서 httpbin 서비스에 액세스할 수 있는지 확인합니다.

    $ oc exec "$(oc get pod -l app=sleep -n <namespace> \
       -o jsonpath={.items..metadata.name})" -c sleep -n <namespace> -- \
       curl http://httpbin.<namespace>:8000/ip -s -o /dev/null \
       -w "%{http_code}\n"

    출력 예:

    200

  3. 수신 게이트웨이에서 httpbin 서비스로 mTLS 트래픽을 확인합니다.

    $ oc apply -n <namespace> -f https://raw.githubusercontent.com/maistra/istio/maistra-2.4/samples/httpbin/httpbin-gateway.yaml
  4. istio-ingressgateway 경로를 가져옵니다.

    INGRESS_HOST=$(oc -n istio-system get routes istio-ingressgateway -o jsonpath='{.spec.host}')
  5. 수신 게이트웨이에서 httpbin 서비스로의 mTLS 트래픽을 확인합니다.

    $ curl -s -I http://$INGRESS_HOST/headers -o /dev/null -w "%{http_code}" -s

2.13.7. 추가 리소스

OpenShift Container Platform 용 cert-manager Operator를 설치하는 방법에 대한 자세한 내용은 cert-manager Operator for Red Hat OpenShift 설치를 참조하십시오.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.