14.6. TLS 인증서를 사용하여 매핑된 서비스 보안


14.6.1. TLS 인증서를 사용하여 사용자 정의 도메인으로 서비스 보안

Knative 서비스에 대한 사용자 정의 도메인을 구성한 후 TLS 인증서를 사용하여 매핑된 서비스를 보호할 수 있습니다. 이렇게 하려면 Kubernetes TLS 시크릿을 생성한 다음 생성한 TLS 시크릿을 사용하도록 DomainMapping CR을 업데이트해야 합니다.

사전 요구 사항

  • Knative 서비스에 대한 사용자 정의 도메인을 구성하고 DomainMapping CR이 작동합니다.
  • 인증 기관 공급자의 TLS 인증서 또는 자체 서명된 인증서가 있습니다.
  • 인증 기관 공급자 또는 자체 서명된 인증서에서 인증서 및 파일을 가져왔습니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. Kubernetes TLS 시크릿을 생성합니다.

    $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>
  2. Kubernetes TLS 보안에 networking.internal.knative.dev/certificate-uid: <id>' 레이블을 추가합니다.

    $ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"

    cert-manager 와 같은 타사 시크릿 공급자를 사용하는 경우 Kubernetes TLS 보안에 레이블을 지정하도록 시크릿 관리자를 구성할 수 있습니다. cert-manager 사용자는 제공되는 시크릿 템플릿을 사용하여 올바른 레이블로 시크릿을 자동으로 생성할 수 있습니다. 이 경우 키만 기반으로 보안 필터링이 수행되지만 이 값은 시크릿에 포함된 인증서 ID와 같은 유용한 정보를 전송할 수 있습니다.

    참고

    cert-manager Operator for Red Hat OpenShift는 기술 프리뷰 기능입니다. 자세한 내용은 cert-manager Operator for Red Hat OpenShift 설명서를 참조하십시오.

  3. 생성한 TLS 시크릿을 사용하도록 DomainMapping CR을 업데이트합니다.

    apiVersion: serving.knative.dev/v1beta1
    kind: DomainMapping
    metadata:
      name: <domain_name>
      namespace: <namespace>
    spec:
      ref:
        name: <service_name>
        kind: Service
        apiVersion: serving.knative.dev/v1
    # TLS block specifies the secret to be used
      tls:
        secretName: <tls_secret_name>

검증

  1. DomainMapping CR 상태가 True 이고 출력의 URL 열에 스키마 https 와 함께 매핑된 도메인이 표시되는지 확인합니다.

    $ oc get domainmapping <domain_name>

    출력 예

    NAME                      URL                               READY   REASON
    example.com               https://example.com               True

  2. 선택 사항: 서비스가 공개적으로 노출되는 경우 다음 명령을 실행하여 서비스를 사용할 수 있는지 확인합니다.

    $ curl https://<domain_name>

    인증서가 자체 서명된 경우 curl 명령에 -k 플래그를 추가하여 확인을 건너뜁니다.

14.6.2. 시크릿 필터링을 사용하여 net-kourier 메모리 사용량 개선

기본적으로 Kubernetes client-go 라이브러리에 대한 정보 제공자 는 특정 유형의 모든 리소스를 가져옵니다. 이로 인해 많은 리소스가 사용 가능한 경우 상당한 오버헤드가 발생할 수 있으므로 메모리 누수로 인해 대규모 클러스터에서 Knative net-kourier Ingress 컨트롤러가 실패할 수 있습니다. 그러나 필터링 메커니즘은 Knative net-kourier 수신 컨트롤러에서 사용할 수 있으므로 컨트롤러가 Knative 관련 시크릿만 가져올 수 있습니다.

OpenShift Serverless Operator 측에서는 기본적으로 보안 필터링이 활성화됩니다. 환경 변수 ENABLE_SECRET_INFORMER_BY_CERT_UID=true 가 기본적으로 net-kourier 컨트롤러 포드에 추가됩니다.

중요

보안 필터링을 활성화하는 경우 모든 시크릿에 networking.internal.knative.dev/certificate-uid: "<id>" 로 레이블이 지정되어야 합니다. 그렇지 않으면 Knative Serving이 탐지되지 않아 오류가 발생합니다. 새 보안 및 기존 보안에 레이블을 지정해야 합니다.

사전 요구 사항

  • OpenShift Container Platform에 대한 클러스터 관리자 권한이 있거나 AWS 또는 OpenShift Dedicated의 Red Hat OpenShift Service에 대한 클러스터 또는 전용 관리자 권한이 있습니다.
  • 애플리케이션 및 기타 워크로드를 생성할 수 있는 역할 및 권한이 있거나 생성한 프로젝트입니다.
  • OpenShift Serverless Operator 및 Knative Serving을 설치합니다.
  • OpenShift CLI(oc)를 설치합니다.

KnativeServing CR(사용자 정의 리소스)의 workloads 필드를 사용하여 ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID 변수를 false 로 설정하여 시크릿 필터링을 비활성화할 수 있습니다.

KnativeServing CR의 예

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: knative-serving
  namespace: knative-serving
spec:
...
  workloads:
    - env:
        - container: controller
          envVars:
            - name: ENABLE_SECRET_INFORMER_FILTERING_BY_CERT_UID
              value: 'false'
      name: net-kourier-controller

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.