10장. 보안

절차

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

   ...
   spec:
     config:
       network:
         internal-encryption: "true"
   ...

2. knative-serving 네임스페이스에서 활성화기 Pod를 다시 시작하여 인증서를 로드합니다.

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

절차

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
      ...

절차

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 플래그를 추가하여 확인을 건너뜁니다.

프로세스

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>
   ...

프로세스

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