10장. 보안

10.1. TLS 인증 구성

TLS( Transport Layer Security )를 사용하여 Knative 트래픽 및 인증을 암호화할 수 있습니다.

TLS는 Knative Kafka에서 지원되는 유일한 트래픽 암호화 방법입니다. Red Hat은 Knative Kafka 리소스에 SASL 및 TLS를 함께 사용하는 것이 좋습니다.

참고

Red Hat OpenShift Service Mesh 통합을 사용하여 내부 TLS를 활성화하려면 다음 절차에 설명된 내부 암호화 대신 mTLS를 사용하여 서비스 메시를 활성화해야 합니다. mTLS로 서비스 메시를 사용할 때 Knative Serving 메트릭 활성화에 대한 설명서를 참조하십시오.

10.1.1. 내부 트래픽에 대한 TLS 인증 활성화

OpenShift Serverless는 기본적으로 TLS 엣지 종료를 지원하므로 최종 사용자의 HTTPS 트래픽이 암호화됩니다. 그러나 OpenShift 경로 뒤의 내부 트래픽은 일반 데이터를 사용하여 애플리케이션으로 전달됩니다. 내부 트래픽에 TLS를 활성화하면 구성 요소 간에 전송된 트래픽이 암호화되므로 이러한 트래픽의 보안이 향상됩니다.

참고

Red Hat OpenShift Service Mesh 통합을 사용하여 내부 TLS를 활성화하려면 다음 절차에 설명된 내부 암호화 대신 mTLS를 사용하여 서비스 메시를 활성화해야 합니다.

중요

내부 TLS 암호화 지원은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 https://access.redhat.com/support/offerings/techpreview/를 참조하십시오.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • OpenShift(oc) CLI를 설치했습니다.

절차

  1. 사양에 internal-encryption: "true" 필드를 포함하는 Knative 서비스를 생성합니다.

    ...
    spec:
      config:
        network:
          internal-encryption: "true"
    ...
  2. knative-serving 네임스페이스에서 활성화기 Pod를 다시 시작하여 인증서를 로드합니다.

    $ oc delete pod -n knative-serving --selector app=activator

10.1.2. 클러스터 로컬 서비스에 대한 TLS 인증 활성화

클러스터 로컬 서비스의 경우 Kourier 로컬 게이트웨이 kourier-internal 이 사용됩니다. Kourier 로컬 게이트웨이에 대해 TLS 트래픽을 사용하려면 로컬 게이트웨이에서 자체 서버 인증서를 구성해야 합니다.

사전 요구 사항

  • OpenShift Serverless Operator 및 Knative Serving이 설치되어 있습니다.
  • 관리자 권한이 있어야 합니다.
  • OpenShift(oc) CLI를 설치했습니다.

절차

  1. knative-serving-ingress 네임스페이스에 서버 인증서를 배포합니다.

    $ export san="knative"
    참고

    이러한 인증서가 < app_name>.<namespace>.svc.cluster.local 에 대한 요청을 제공할 수 있도록 SAN(Subject Alternative Name) 검증이 필요합니다.

  2. 루트 키 및 인증서를 생성합니다.

    $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
        -subj '/O=Example/CN=Example' \
        -keyout ca.key \
        -out ca.crt
  3. SAN 검증을 사용하는 서버 키를 생성합니다.

    $ openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key \
      -subj "/CN=Example/O=Example" \
      -addext "subjectAltName = DNS:$san"
  4. 서버 인증서를 생성합니다.

    $ openssl x509 -req -extfile <(printf "subjectAltName=DNS:$san") \
      -days 365 -in tls.csr \
      -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt
  5. Kourier 로컬 게이트웨이의 시크릿을 구성합니다.

    1. 이전 단계에서 생성한 인증서에서 knative-serving-ingress 네임스페이스에 보안을 배포합니다.

      $ oc create -n knative-serving-ingress secret tls server-certs \
          --key=tls.key \
          --cert=tls.crt --dry-run=client -o yaml | oc apply -f -
    2. Kourier 게이트웨이에서 생성한 보안을 사용하도록 KnativeServing CR(사용자 정의 리소스) 사양을 업데이트합니다.

      KnativeServing CR의 예

      ...
      spec:
        config:
          kourier:
            cluster-cert-secret: server-certs
      ...

Kourier 컨트롤러는 서비스를 재시작하지 않고 인증서를 설정하므로 Pod를 다시 시작할 필요가 없습니다.

클라이언트의 ca.crt 를 마운트하고, 포트 443 을 통해 TLS를 사용하여 Kourier 내부 서비스에 액세스할 수 있습니다.

10.1.3. 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. Red Hat OpenShift Service Mesh를 OpenShift Serverless 설치의 수신으로 사용하는 경우 다음을 사용하여 Kubernetes TLS 시크릿에 레이블을 지정합니다.

    “networking.internal.knative.dev/certificate-uid": “<value>”

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

    참고

    {cert-manager-operator}는 기술 프리뷰 기능입니다. 자세한 내용은 {cert-manager-operator} 설명서 설치를 참조하십시오.

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

    apiVersion: serving.knative.dev/v1alpha1
    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 플래그를 추가하여 확인을 건너뜁니다.

10.1.4. Kafka 브로커의 TLS 인증 구성

TLS( Transport Layer Security )는 Apache Kafka 클라이언트와 서버에서 Knative와 Kafka 간의 트래픽 암호화 및 인증에 사용됩니다. TLS는 Knative Kafka에서 지원되는 유일한 트래픽 암호화 방법입니다.

사전 요구 사항

  • OpenShift Container Platform에 대한 클러스터 관리자 권한이 있습니다.
  • OpenShift Serverless Operator, Knative Eventing, KnativeKafka CR이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • Kafka 클러스터 CA 인증서가 .pem 파일로 저장되어 있습니다.
  • Kafka 클러스터 클라이언트 인증서와 .pem 파일로 저장된 키가 있습니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. knative-eventing 네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.

    $ oc create secret -n knative-eventing generic <secret_name> \
      --from-literal=protocol=SSL \
      --from-file=ca.crt=caroot.pem \
      --from-file=user.crt=certificate.pem \
      --from-file=user.key=key.pem
    중요

    키 이름 ca.crt,user.crt, user.key를 사용합니다. 이 값은 변경하지 마십시오.

  2. KnativeKafka CR을 편집하고 broker 사양에 보안에 대한 참조를 추가합니다.

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      broker:
        enabled: true
        defaultConfig:
          authSecretName: <secret_name>
    ...

10.1.5. Kafka 채널의 TLS 인증 구성

TLS( Transport Layer Security )는 Apache Kafka 클라이언트와 서버에서 Knative와 Kafka 간의 트래픽 암호화 및 인증에 사용됩니다. TLS는 Knative Kafka에서 지원되는 유일한 트래픽 암호화 방법입니다.

사전 요구 사항

  • OpenShift Container Platform에 대한 클러스터 관리자 권한이 있습니다.
  • OpenShift Serverless Operator, Knative Eventing, KnativeKafka CR이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • Kafka 클러스터 CA 인증서가 .pem 파일로 저장되어 있습니다.
  • Kafka 클러스터 클라이언트 인증서와 .pem 파일로 저장된 키가 있습니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. 선택한 네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.

    $ oc create secret -n <namespace> generic <kafka_auth_secret> \
      --from-file=ca.crt=caroot.pem \
      --from-file=user.crt=certificate.pem \
      --from-file=user.key=key.pem
    중요

    키 이름 ca.crt,user.crt, user.key를 사용합니다. 이 값은 변경하지 마십시오.

  2. KnativeKafka 사용자 정의 리소스 편집을 시작합니다.

    $ oc edit knativekafka
  3. 시크릿 및 시크릿의 네임스페이스를 참조합니다.

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: <kafka_auth_secret>
        authSecretNamespace: <kafka_auth_secret_namespace>
        bootstrapServers: <bootstrap_servers>
        enabled: true
      source:
        enabled: true
    참고

    부트스트랩 서버에서 일치하는 포트를 지정해야 합니다.

    예를 들면 다음과 같습니다.

    apiVersion: operator.serverless.openshift.io/v1alpha1
    kind: KnativeKafka
    metadata:
      namespace: knative-eventing
      name: knative-kafka
    spec:
      channel:
        authSecretName: tls-user
        authSecretNamespace: kafka
        bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9094
        enabled: true
      source:
        enabled: true