커스텀 클러스터 인증 기관 사용

클러스터 인증 기관(CA)은 인증서를 발급하고 서명하여 클러스터 구성요소 간의 보안 인증 및 암호화를 지원합니다. 기본적으로 베어메탈용 GKE에서는 새 클러스터를 만들 때 클러스터 API가 클러스터 CA를 만듭니다. 이 문서에서는 베어메탈용 GKE에서 고유한 인증 기관을 사용하는 방법을 설명합니다. 커스텀 클러스터 CA를 사용하면 클러스터 인증서를 발급하고 관리하는 더 많은 제어 기능을 사용할 수 있습니다. 또한 신뢰, 암호화 알고리즘 매개변수, 하위 인증서의 깊이와 목적을 제어할 수 있습니다.

커스텀 CA를 사용하려면 CA 인증서 파일 및 해당 비공개 키 파일로 구성된 루트 CA를 제공해야 합니다. 다음과 같은 각 필수 클러스터 CA에 대해 CA 인증서/키 파일 쌍을 제공합니다.

  • etcd CA: etcd CA 인증서는 Kubernetes API 서버에서 etcd 복제본으로의 통신과 etcd 복제본 간 통신도 보호합니다.

  • 클러스터 CA: 클러스터 CA의 인증서는 Kubernetes API 서버와 모든 내부 Kubernetes API 클라이언트 사이의 통신을 보호합니다. 클라이언트에는 kubelet, 컨트롤러 관리자, 스케줄러가 포함됩니다.

  • 프런트 프록시 CA: 프런트 프록시 CA의 인증서는 집계된 API와의 통신을 보호합니다.

각 CA에 대해 고유 인증서/키 쌍을 제공하거나 둘 이상의 CA에 인증서/키 쌍을 재사용할 수 있습니다.

클러스터 만들기(bmctl 메서드만 해당) 및 CA 순환 중에 인증서/키 쌍을 적용합니다. 커스텀 클러스터 CA 기능은 관리자, 사용자, 하이브리드, 독립형의 모든 클러스터 유형에서 작동합니다.

기본 요건

사용자는 다음 규칙에 따라 자체 루트 CA를 준비해야 합니다.

  • 커스텀 CA는 루트 CA이며 각각 자체 서명된 인증서 파일과 비공개 키 파일로 구성됩니다.

  • 중개 CA 및 하위 CA는 지원되지 않습니다.

  • 인증서에 대해 고유 인코딩 규칙(DER) 형식을 사용하는 것이 좋습니다(ASN.1 인코딩 규칙에 대한 권장사항 X.690 참조). 인증서 파일에는 base64로 인코딩된 데이터(앞에는 ‑‑‑‑‑BEGIN CERTIFICATE‑‑‑‑‑, 뒤에는 ‑‑‑‑END CERTIFICATE‑‑‑‑‑가 있음)가 포함되어야 합니다.

  • 비공개 키의 경우 공개 키 암호화 표준(PKCS) #1 형식을 사용하는 것이 좋습니다. 키 파일에는 base64로 인코딩된 데이터(앞에는 ‑‑‑‑BEGIN RSA PRIVATE KEY‑‑‑‑, 뒤에는 ‑‑‑‑END RSA PRIVATE KEY‑‑‑‑가 있음)가 포함되어야 합니다.

  • 잠재적인 클러스터 중단을 최소화하기 위해서는 커스텀 CA가 5년 이내에 만료되지 않아야 합니다. 만료 시간을 10~30년 정도로 길게 설정하는 것이 좋습니다.

  • 인증서와 키 파일은 bmctl CLI를 실행하는 관리자 워크스테이션에 있어야 합니다.

  • bmctl 명령어를 실행하는 사용자는 파일을 저장하는 디렉터리에 대한 액세스 권한이 있어야 합니다. 인증서 및 키에 사용되는 기존 디렉터리에 파일을 배치하는 것이 좋습니다. 예를 들어 서비스 계정 키와 함께 ~/baremetal/bmctl-workspace/.sa-keys에 파일을 저장할 수 있습니다.

  • bmctl 명령어를 실행하는 사용자는 파일에 대한 읽기 권한이 있어야 합니다.

클러스터 생성 중 커스텀 CA 사용

bmctl로 클러스터를 만들 때는 먼저 클러스터 구성 파일을 업데이트하여 클러스터 기능 및 설정을 기술합니다. 클러스터를 만드는 동안 커스텀 클러스터 CA 기능을 사용하려면 클러스터 구성 파일에 커스텀 클러스터 CA를 지정하는 두 가지 옵션이 있습니다.

  • CA 인증서 파일과 비공개 키 파일의 경로 지정
  • 비공개 키 파일의 경로만 지정

비공개 키만 지정하면 bmctl이 동일한 디렉터리에서 해당 CA 인증서 파일을 찾습니다. 인증서 파일 이름은 해당하는 비공개 키 파일 및 .crt 파일 확장자와 동일해야 합니다. 예를 들어 비공개 키 경로가 /custom-ca/cluster_ca.key이면 bmctl은 인증서 경로를 /custom-ca/cluster_ca.crt으로 간주합니다.

어느 경우에나 경로는 다음 예시에 표시된 대로 구성 파일의 사용자 인증 정보 섹션에 지정됩니다.

예시 1: 인증서와 키 경로 지정

다음과 같은 클러스터 구성 파일의 발췌물은 각 클러스터 CA의 인증서 및 키 파일 모두에 경로를 지정하는 방법을 보여줍니다. 이 예시에서 CA 인증서와 키 파일은 서비스 계정 JSON 키 파일과 동일한 디렉터리에 있습니다.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCACertPath: bmctl-workspace/.sa-keys/cluster_ca_cert.pem
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCACertPath: bmctl-workspace/.sa-keys/etcd_ca_cert.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCACertPath: bmctl-workspace/.sa-keys/front_proxy_ca_cert.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

예시 2: 비공개 키 경로만 지정

다음과 같은 클러스터 구성 파일의 발췌문은 키 파일 경로만 지정하는 방법을 보여줍니다. 이 예시에서 CA 비공개 키 파일은 서비스 계정 JSON 키 파일과 동일한 디렉터리에 있습니다. 해당 CA 인증서 파일은 /.sa-keys 디렉터리에도 있어야 합니다. 인증서 파일은 키 파일과 이름이 같지만 .crt 확장자가 사용됩니다. 따라서 etcd CA 인증서 파일 이름은 etcd_ca.crt입니다.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: bmctl-workspace/.sa-keys/cluster_ca_key.pem
etcdCAPrivateKeyPath: bmctl-workspace/.sa-keys/etcd_ca_key.pem
frontProxyCAPrivateKeyPath: bmctl-workspace/.sa-keys/front_proxy_ca_key.pem
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

예시 3: CA 인증서와 키 파일의 단일 쌍 재사용

다음과 같은 클러스터 구성 파일의 발췌문은 키 파일 경로만 지정하는 방법을 보여줍니다. 이 예시에서는 단일 인증서/키 쌍을 모든 클러스터 CA에 사용합니다. CA 인증서와 비공개 키 파일은 모두 /custom-ca 디렉터리에 있습니다. 이름 지정 규칙에 따라 CA 인증서 파일 이름은 custom_ca.crt입니다.

gcrKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-gcr.json
...
cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/myproject-anthos-baremetal-cloud-ops.json
clusterCAPrivateKeyPath: /custom-ca/custom_ca.key
etcdCAPrivateKeyPath: /custom-ca/custom_ca.key
frontProxyCAPrivateKeyPath: /custom-ca/custom_ca.key
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-admin-test
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
...

CA 순환 중 커스텀 CA 사용

CA를 순환할 때 커스텀 클러스터 CA 인증서 및 비공개 키 파일의 경로를 지정할 수 있습니다. 제공되는 옵션은 클러스터를 만들 때 커스텀 클러스터 CA를 지정하는 옵션과 유사합니다. bmctl update credentials certificate-authorities rotate 명령어를 실행할 때 옵션은 다음과 같습니다.

  • 커스텀 CA 인증서 파일과 비공개 키 파일 모두의 경로를 지정합니다.
  • 커스텀 CA 비공개 키 파일의 경로만 지정합니다. 해당 CA 인증서 파일은 동일한 디렉터리에 있어야 하고 키 파일과 이름이 동일하며 .crt 파일 확장자를 가져야 합니다.
  • 둘 이상의 클러스터 CA에 대해 동일한 인증서 및 키 경로를 지정하여 CA 인증서/키 쌍을 재사용합니다.
  • 커스텀 CA 경로의 인수를 생략합니다. CA를 순환할 때 커스텀 CA 경로를 지정하지 않으면 베어메탈용 GKE에서 표준 클러스터 CA를 만들어 사용합니다.

예시 1: CA 인증서 및 비공개 키 경로 지정

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-cert-path=CLUSTER_CA_CERT_PATH \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-cert-path=ETCD_CA_CERT_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-cert-path=FRONT_PROXY_CA_CERT_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

다음을 바꿉니다.

  • CLUSTER_NAME: CA를 순환하려는 클러스터의 이름입니다.
  • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로 자체 관리 클러스터의 경우 이 파일은 클러스터의 kubeconfig 파일입니다.
  • CLUSTER_CA_CERT_PATH: 클러스터 CA 인증서 파일의 경로입니다.
  • CLUSTER_CA_KEY_PATH: 클러스터 CA 비공개 키 파일의 경로입니다.
  • ETCD_CA_CERT_PATH: etcd CA 인증서 파일의 경로입니다.
  • ETCD_CA_KEY_PATH: etcd CA 비공개 키 파일의 경로입니다.
  • FRONT_PROXY_CA_CERT_PATH: 프런트 프록시 인증서 파일의 경로입니다.
  • FRONT_PROXY_CA_KEY_PATH: 프런트 프록시 비공개 키 파일의 경로입니다.

예시 2: 비공개 키 경로만 지정

bmctl update credentials certificate-authorities rotate \
    --cluster CLUSTER_NAME \
    --kubeconfig ADMIN_KUBECONFIG \
    --cluster-ca-private-key-path=CLUSTER_CA_KEY_PATH \
    --etcd-ca-private-key-path=ETCD_CA_KEY_PATH \
    --front-proxy-ca-private-key-path=FRONT_PROXY_CA_KEY_PATH

다음을 바꿉니다.

  • CLUSTER_NAME: CA를 순환하려는 클러스터의 이름입니다.
  • ADMIN_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로 자체 관리 클러스터의 경우 이 파일은 클러스터의 kubeconfig 파일입니다.
  • CLUSTER_CA_KEY_PATH: 클러스터 CA 비공개 키 파일의 경로입니다.
  • ETCD_CA_KEY_PATH: etcd CA 비공개 키 파일의 경로입니다.
  • FRONT_PROXY_CA_KEY_PATH: 프런트 프록시 비공개 키 파일의 경로입니다.