3.3. 서비스 제공 인증서 보안을 사용하여 서비스 트래픽 보안

프로세스

1. service.beta.openshift.io/serving-cert-secret-name으로 서비스에 주석을 답니다.

   $ oc annotate service <service_name> \1
        service.beta.openshift.io/serving-cert-secret-name=<secret_name> 2

   1

   <service_name>을 보호할 서비스 이름으로 교체합니다.

   2

   <secret_name>은 인증서와 키 쌍이 포함되어 생성된 보안의 이름입니다. <service_name>과 동일하게 설정하면 편리합니다.

   예를 들어 서비스 test1에 주석을 달려면 다음 명령을 사용합니다.

   $ oc annotate service test1 service.beta.openshift.io/serving-cert-secret-name=test1

2. 서비스를 검사하여 주석이 있는지 확인합니다.

   $ oc describe service <service_name>

   출력 예

   ...
   Annotations:              service.beta.openshift.io/serving-cert-secret-name: <service_name>
                             service.beta.openshift.io/serving-cert-signed-by: openshift-service-serving-signer@1556850837
   ...

3. 클러스터에서 서비스 보안을 생성하면 Pod 사양에서 보안을 마운트하고, 사용 가능 상태가 되면 Pod에서 실행합니다.

프로세스

1. service.beta.openshift.io/inject-cabundle=true로 구성 맵에 주석을 답니다.

   $ oc annotate configmap <config_map_name> \1
        service.beta.openshift.io/inject-cabundle=true

   1

   <config_map_name>을 주석을 달 구성 맵 이름으로 교체합니다.

   참고

   볼륨 마운트 시 service-ca.crt 키를 명시적으로 참조하면 CA 번들로 구성 맵을 삽입할 때까지 Pod가 시작되지 않습니다. 이 동작은 볼륨 제공 인증서 구성에서 optional 필드를 true로 설정하여 덮어쓸 수 있습니다.

   예를 들어 구성 맵 test1에 주석을 달려면 다음 명령을 사용합니다.

   $ oc annotate configmap test1 service.beta.openshift.io/inject-cabundle=true

2. 구성 맵을 보고 서비스 CA 번들이 삽입되었는지 확인합니다.

   $ oc get configmap <config_map_name> -o yaml

   CA 번들은 YAML 출력에서 service-ca.crt 키 값으로 표시됩니다.

   apiVersion: v1
   data:
     service-ca.crt: |
       -----BEGIN CERTIFICATE-----
   ...

프로세스

1. service.beta.openshift.io/inject-cabundle=true로 API 서비스에 주석을 답니다.

   $ oc annotate apiservice <api_service_name> \1
        service.beta.openshift.io/inject-cabundle=true

   1

   <api_service_name>을 주석을 달 API 서비스 이름으로 교체합니다.

   예를 들어 API 서비스 test1에 주석을 달려면 다음 명령을 사용합니다.

   $ oc annotate apiservice test1 service.beta.openshift.io/inject-cabundle=true

2. API 서비스를 보고 서비스 CA 번들이 삽입되었는지 확인합니다.

   $ oc get apiservice <api_service_name> -o yaml

   CA 번들은 YAML 출력의 spec.caBundle 필드에 표시됩니다.

   apiVersion: apiregistration.k8s.io/v1
   kind: APIService
   metadata:
     annotations:
       service.beta.openshift.io/inject-cabundle: "true"
   ...
   spec:
     caBundle: <CA_BUNDLE>
   ...

프로세스

1. service.beta.openshift.io/inject-cabundle=true로 CRD에 주석을 답니다.

   $ oc annotate crd <crd_name> \1
        service.beta.openshift.io/inject-cabundle=true

   1

   <crd_name>을 주석을 달 CRD 이름으로 교체합니다.

   예를 들어 CRD test1에 주석을 달려면 다음 명령을 사용합니다.

   $ oc annotate crd test1 service.beta.openshift.io/inject-cabundle=true

2. CRD를 보고 서비스 CA 번들이 삽입되었는지 확인합니다.

   $ oc get crd <crd_name> -o yaml

   CA 번들은 YAML 출력의 spec.conversion.webhook.clientConfig.caBundle 필드에 표시됩니다.

   apiVersion: apiextensions.k8s.io/v1
   kind: CustomResourceDefinition
   metadata:
     annotations:
       service.beta.openshift.io/inject-cabundle: "true"
   ...
   spec:
     conversion:
       strategy: Webhook
       webhook:
         clientConfig:
           caBundle: <CA_BUNDLE>
   ...

프로세스

1. service.beta.openshift.io/inject-cabundle=true로 변경 웹 후크 구성에 주석을 답니다.

   $ oc annotate mutatingwebhookconfigurations <mutating_webhook_name> \1
        service.beta.openshift.io/inject-cabundle=true

   1

   <mutating_webhook_name>을 주석을 달 변경 웹 후크 구성 이름으로 교체합니다.

   예를 들어 변경 웹 후크 구성 test1에 주석을 달려면 다음 명령을 사용합니다.

   $ oc annotate mutatingwebhookconfigurations test1 service.beta.openshift.io/inject-cabundle=true

2. 변경 웹 후크 구성을 보고 서비스 CA 번들이 삽입되었는지 확인합니다.

   $ oc get mutatingwebhookconfigurations <mutating_webhook_name> -o yaml

   CA 번들은 YAML 출력에 있는 모든 웹 후크의 clientConfig.caBundle 필드에 표시됩니다.

   apiVersion: admissionregistration.k8s.io/v1
   kind: MutatingWebhookConfiguration
   metadata:
     annotations:
       service.beta.openshift.io/inject-cabundle: "true"
   ...
   webhooks:
   - myWebhook:
     - v1beta1
     clientConfig:
       caBundle: <CA_BUNDLE>
   ...

프로세스

1. service.beta.openshift.io/inject-cabundle=true로 검증 웹 후크 구성에 주석을 답니다.

   $ oc annotate validatingwebhookconfigurations <validating_webhook_name> \1
        service.beta.openshift.io/inject-cabundle=true

   1

   <validating_webhook_name>을 주석을 달 검증 웹 후크 구성 이름으로 교체합니다.

   예를 들어 검증 웹 후크 구성 test1에 주석을 달려면 다음 명령을 사용합니다.

   $ oc annotate validatingwebhookconfigurations test1 service.beta.openshift.io/inject-cabundle=true

2. 검증 웹 후크 구성을 보고 서비스 CA 번들이 삽입되었는지 확인합니다.

   $ oc get validatingwebhookconfigurations <validating_webhook_name> -o yaml

   CA 번들은 YAML 출력에 있는 모든 웹 후크의 clientConfig.caBundle 필드에 표시됩니다.

   apiVersion: admissionregistration.k8s.io/v1
   kind: ValidatingWebhookConfiguration
   metadata:
     annotations:
       service.beta.openshift.io/inject-cabundle: "true"
   ...
   webhooks:
   - myWebhook:
     - v1beta1
     clientConfig:
       caBundle: <CA_BUNDLE>
   ...

프로세스

1. 서비스를 검사하여 인증서가 포함된 보안을 판별합니다. 아래 표시된 대로 serving-cert-secret-name 주석에 있습니다.

   $ oc describe service <service_name>

   출력 예

   ...
   service.beta.openshift.io/serving-cert-secret-name: <secret>
   ...

2. 서비스용으로 생성된 보안을 삭제합니다. 이 프로세스는 자동으로 보안을 재생성합니다.

   $ oc delete secret <secret> 1

   1

   <secret>을 이전 단계의 보안 이름으로 교체합니다.

3. 새 보안을 확보하고 AGE를 검사하여 인증서가 다시 생성되었는지 확인합니다.

   $ oc get secret <service_name>

   출력 예

   NAME              TYPE                DATA   AGE
   <service.name>    kubernetes.io/tls   2      1s

프로세스

1. 다음 명령을 사용하여 현재 서비스 CA 인증서의 만료 날짜를 봅니다.

   $ oc get secrets/signing-key -n openshift-service-ca \
        -o template='{{index .data "tls.crt"}}' \
        | base64 --decode \
        | openssl x509 -noout -enddate

2. 서비스 CA를 직접 순환합니다. 이 프로세스는 새로운 서비스 인증서에 서명하는 데 사용될 새로운 서비스 CA를 생성합니다.

   $ oc delete secret/signing-key -n openshift-service-ca

3. 새 인증서를 모든 서비스에 적용하도록 클러스터의 모든 Pod를 다시 시작합니다. 이 명령을 실행하면 모든 서비스가 업데이트된 인증서를 사용합니다.

   $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
         do oc delete pods --all -n $I; \
         sleep 1; \
         done

   주의

   이 명령은 모든 네임스페이스에서 실행 중인 모든 Pod를 대상으로 진행하고 삭제하므로 서비스가 중단됩니다. 이 Pod는 삭제 후 자동으로 다시 시작됩니다.