이 페이지에서는 Google Kubernetes Engine(GKE)에서 Kubernetes API 서버에 연결할 때 지원되는 인증 방법을 설명합니다.
Kubernetes 워크로드를 Google Cloud API에 인증하는 방법에 대한 자세한 내용은 워크로드 아이덴티티를 참조하세요.
개요
Kubernetes API 서버에 인증하는 방법은 몇 가지가 있습니다. GKE에서는 OAuth 인증이 클러스터 인증에 권장되며 자동으로 구성됩니다.
시작하기 전에
시작하기 전에 다음 태스크를 수행했는지 확인합니다.
- Google Kubernetes Engine API가 사용 설정되었는지 확인합니다. Google Kubernetes Engine API 사용 설정
- Cloud SDK가 설치되었는지 확인합니다.
다음 방법 중 하나를 사용하여 기본 gcloud
설정을 진행합니다.
gcloud init
를 사용하여 기본값 설정 과정을 진행합니다.gcloud config
를 사용하여 프로젝트 ID, 영역, 리전을 개별적으로 설정합니다.
gcloud init 사용
One of [--zone, --region] must be supplied: Please specify
location
오류가 표시되면 이 섹션을 완료합니다.
-
gcloud init
를 실행하고 다음 안내를 따르세요.gcloud init
원격 서버에서 SSH를 사용하는 경우
--console-only
플래그를 사용하여 다음 명령어로 브라우저를 실행하지 못하게 할 수 있습니다.gcloud init --console-only
- 안내를 따라
gcloud
에서 Google Cloud 계정을 사용하도록 승인합니다. - 새 구성을 만들거나 기존 구성을 선택합니다.
- Google Cloud 프로젝트를 선택합니다.
- 기본 Compute Engine 영역을 선택합니다.
gcloud config 사용
사용자 인증
GKE는 gcloud
명령줄 도구를 통해 최종 사용자 인증을 관리합니다. gcloud
도구는 사용자를 Google Cloud에 인증하고, Kubernetes 구성을 설정하고, 클러스터의 OAuth 액세스 토큰을 가져오고, 액세스 토큰을 최신 상태로 유지합니다. ID 및 액세스 관리(IAM) 또는 Kubernetes 역할 기반 액세스 제어(RBAC)로 클러스터에 대한 액세스를 제어할 수 있습니다.
GKE가 OAuth와 통합되기 전에는 사전 프로비저닝된 x509 인증서 또는 정적 비밀번호가 유일하게 사용 가능한 인증 방법이었지만 이제는 권장되지 않으며 GKE 버전 1.12 이상부터는 새 클러스터에서 기본적으로 사용 중지됩니다. 기존 인증 방법을 사용 중인 경우 이러한 방법에서 벗어나는 것이 좋습니다.
OAuth를 사용하여 인증
OAuth 방법을 사용하여 클러스터에 인증하려면 다음을 수행합니다.
사용자 인증 정보를 사용하여
gcloud
도구에 로그인합니다. 이렇게 하면 Google Cloud에 대한 인증 프로세스를 완료할 웹브라우저가 열립니다.gcloud auth login
특정 클러스터의 Kubernetes 사용자 인증 정보를 검색합니다.
gcloud container clusters get-credentials CLUSTER_NAME \ --zone=COMPUTE_ZONE
이제 인증되었습니다. 다음
kubectl
명령어를 사용하여 결과를 확인합니다.kubectl cluster-info
서비스 인증
사용자 상호작용(예: CI/CD 파이프라인 스크립트) 없이 서비스에서 GKE 클러스터의 API 서버에 인증해야 하는 경우가 있습니다. 이를 수행하는 방법은 서비스가 실행되는 환경에 따라 다릅니다.
동일한 GKE 클러스터 내의 서비스
연결하려는 GKE 클러스터 내부의 pod에서 서비스가 실행 중인 경우 Kubernetes 서비스 계정을 사용하여 인증합니다.
Kubernetes 서비스 계정을 만들어 pod에 연결합니다. pod에 이미 Kubernetes 서비스 계정이 있는 경우 이 단계를 건너뛸 수 있습니다.
이 예시에서는
cicd-ns
네임스페이스에cicd
라는 Kubernetes 서비스 계정을 사용합니다.Kubernetes RBAC를 사용하여 Kubernetes 서비스 계정에 올바른 권한을 부여합니다.
이 예시에서는
prod
네임스페이스에edit
역할을 부여하지만 실제로는 요구사항에 적합한 역할을 부여해야 합니다.kubectl create rolebinding cicd \ --clusterrole=edit \ --serviceaccount=cicd-ns:cicd \ --namespace=prod
런타임 시 서비스가
kubectl
을 호출하면 구성한 사용자 인증 정보가 자동으로 수신됩니다.
Google Cloud 내 서비스
서비스가 Google Cloud(예: Compute Engine VM 또는 다른 GKE 클러스터) 내에서 실행되는 경우 환경에서 사용할 수 있는 Google 서비스 계정 사용자 인증 정보를 사용하여 API 서버에 인증해야 합니다.
Compute Engine 환경에 Google 서비스 계정을 할당합니다. 서비스가 Compute Engine VM 내에서 실행되는 경우 인스턴스에 Google 서비스 계정을 할당합니다. 서비스가 GKE 클러스터 내에서 실행되는 경우 워크로드 아이덴티티를 사용하여 pod가 Google 서비스 계정으로 실행되도록 구성합니다.
이 예시에서는
ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
을 Google 서비스 계정으로 사용합니다.Google 서비스 계정에 원하는 클러스터에 대한 액세스 권한을 부여합니다.
이 예시에서는 클러스터 내의 Kubernetes API 객체에 대한 액세스 권한을 제공하는
roles/container.developer
IAM 역할을 부여합니다.gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/container.developer
클러스터 사용자 인증 정보를 검색합니다.
gcloud container clusters get-credentials CLUSTER_NAME \ --zone=COMPUTE_ZONE
서비스는 환경에 설정된 Google 서비스 계정을 사용하여 자동으로 인증됩니다.
다른 환경의 서비스
Google Cloud 외부 환경에서 서비스를 인증하면 관리되는 Google 서비스 계정 사용자 인증 정보에 서비스가 액세스할 수 없습니다. 클러스터 사용자 인증 정보를 검색하려면 Google 서비스 계정을 만들고, 키를 다운로드하고, 런타임에 서비스에서 키를 사용하여 gcloud
도구로 클러스터 사용자 인증 정보를 검색해야 합니다.
서비스의 Google 서비스 계정을 만듭니다. 이미 Google 서비스 계정이 있다면 이 단계를 건너뛰어도 됩니다.
이 예시에서는 이름이
ci-cd-pipeline
인 서비스 계정을 만듭니다.gcloud iam service-accounts create ci-cd-pipeline
Google 서비스 계정에 클러스터 액세스 권한을 부여합니다.
이 예시에서는
ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
을 Google 서비스 계정으로 사용하고, 클러스터 내 Kubernetes API 객체에 대한 액세스 권한을 제공하는roles/container.developer
IAM 역할을 부여합니다.gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/container.developer
IAM을 사용하여 액세스 권한을 부여했습니다. 또한 Kubernetes RBAC를 사용하여 이 액세스 권한을 부여하면 보다 세밀하게 액세스를 제어할 수 있습니다.
Google 서비스 계정의 키를 만들고 다운로드합니다. 런타임에 이 키를 서비스에 제공합니다.
gcloud iam service-accounts keys create gsa-key.json \ --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
런타임에 서비스를 실행하는 환경에서 Google 서비스 계정 키를 사용하여
gcloud
도구에 인증합니다.gcloud auth activate-service-account ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com \ --key-file=gsa-key.json
환경에
gcloud
도구를 설치해야 합니다.gcloud
도구를 설치하는 방법은 Cloud SDK 설치를 참조하세요. 환경에gcloud
도구를 설치할 수 없는 경우 gcloud가 없는 환경 섹션을 참조하세요.gcloud
도구를 사용하여 클러스터 사용자 인증 정보를 검색합니다.gcloud config set project PROJECT_ID gcloud container clusters get-credentials CLUSTER_NAME \ --zone=COMPUTE_ZONE
gcloud가 없는 환경
gcloud
도구를 사용하여 클러스터 사용자 인증 정보를 검색하는 것이 좋습니다. 이 방법은 제어 영역 IP 순환 또는 사용자 인증 정보 순환 같은 클러스터 이벤트에 대한 복원력이 우수하기 때문입니다.
그러나 환경에 gcloud
도구를 설치할 수 없다면 정적 kubeconfig 파일을 만들어 클러스터에 인증할 수 있습니다.
서비스의 Google 서비스 계정을 만듭니다. 이미 Google 서비스 계정이 있다면 이 단계를 건너뛰어도 됩니다.
이 예시에서는 이름이
ci-cd-pipeline
인 서비스 계정을 만듭니다.gcloud iam service-accounts create ci-cd-pipeline
Google 서비스 계정에 클러스터 액세스 권한을 부여합니다.
이 예시에서는
ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
을 Google 서비스 계정으로 사용하고, 클러스터 내 Kubernetes API 객체에 대한 액세스 권한을 제공하는roles/container.developer
IAM 역할을 부여합니다.gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com --role=roles/container.developer
IAM을 사용하여 액세스 권한을 부여했습니다. 또한 Kubernetes RBAC를 사용하여 이 액세스 권한을 부여하면 보다 세밀하게 액세스를 제어할 수 있습니다.
Google 서비스 계정의 키를 만들고 다운로드합니다.
이 예시에서 키 파일의 이름은
gsa-key.json
입니다.gcloud iam service-accounts keys create gsa-key.json \ --iam-account=ci-cd-pipeline@PROJECT_ID.iam.gserviceaccount.com
클러스터의
endpoint
및clusterCaCertificate
값을 가져옵니다.gcloud container clusters describe CLUSTER_NAME \ --zone=COMPUTE_ZONE \ --format="value(endpoint)" gcloud container clusters describe CLUSTER_NAME \ --zone=COMPUTE_ZONE \ --format="value(masterAuth.clusterCaCertificate)"
다음이 포함된
kubeconfig.yaml
파일을 만듭니다.apiVersion: v1 kind: Config clusters: - name: CLUSTER_NAME cluster: server: https://endpoint certificate-authority-data: masterAuth.clusterCaCertificate users: - name: ci-cd-pipeline-gsa user: auth-provider: name: gcp contexts: - context: cluster: CLUSTER_NAME user: ci-cd-pipeline-gsa name: CLUSTER_NAME-ci-cd current-context: CLUSTER_NAME-ci-cd
다음을 바꿉니다.
- CLUSTER_NAME: 클러스터 이름입니다.
- endpoint: 이전 단계에서 가져온
endpoint
값입니다. - masterAuth.clusterCaCertificate: 이전 단계에서 가져온
clusterCaCertificate
값입니다(base64 인코딩 인증서를 디코딩할 필요가 없음).
사용자 환경의 서비스와 함께
kubeconfig.yaml
및gsa-key.json
을 배포합니다. 런타임에 서비스를 실행하는 환경에서 다음 환경 변수를 설정합니다.export KUBECONFIG=path/to/kubeconfig.yaml export GOOGLE_APPLICATION_CREDENTIALS=path/to/gsa-key.json
이제 서비스가
kubectl
을 호출할 수 있으며 Google 서비스 계정으로 인증됩니다.
기존 인증 방법
GKE가 Google OAuth와 통합되기 전에는 1회 생성된 x509 인증서나 정적 비밀번호가 유일하게 사용 가능한 인증 방법이었지만 이제는 권장되지 않으며 사용 중지해야 합니다. 이러한 방법은 클러스터를 손상시킬 수 있는 공격 범위가 넓으며 GKE 버전 1.12 이후부터는 기본적으로 사용 중지되었습니다. 기존 인증 방법을 사용하는 경우 중지하는 것이 좋습니다. 정적 비밀번호를 사용하는 인증은 지원 중단되었으며 GKE 버전 1.19 이후부터는 삭제되었습니다.
사용 설정될 경우 container.clusters.getCredentials
권한이 있는 사용자가 클라이언트 인증서와 정적 비밀번호를 검색할 수 있습니다. roles/container.admin
, roles/owner
, roles/editor
역할 모두에 이 권한이 포함되므로 이러한 역할은 현명하게 사용해야 합니다. GKE의 Cloud IAM 역할에 대해 자세히 알아보세요.
정적 비밀번호를 사용한 인증 사용 중지
정적 비밀번호는 API 서버가 검증하는 사용자 이름과 비밀번호의 조합입니다. GKE에서는 이 인증 방법을 기본 인증이라고 합니다.
기존 클러스터를 업데이트하고 정적 암호를 삭제하려면 다음을 사용하세요.
gcloud container clusters update CLUSTER_NAME --no-enable-basic-auth
클라이언트 인증서를 사용한 인증 사용 중지
인증서 인증의 경우 클라이언트는 API 서버가 지정된 인증 기관에 확인하는 인증서를 제공합니다. GKE에서 클라이언트 인증서는 클러스터 루트 인증 기관(CA)에 의해 서명됩니다.
클라이언트 인증서 인증은 Kubernetes API 서버에 대한 승인에 영향을 미칩니다. 클러스터에서 기존 속성 기반 액세스 제어(ABAC) 승인이 사용 설정된 경우 클라이언트 인증서는 기본적으로 API 서버에서 인증 및 모든 작업을 수행할 수 있습니다. 반면 역할 기반 액세스 제어(RBAC)가 사용 설정된 경우 클라이언트 인증서에 Kubernetes 리소스에 대한 특정 승인이 부여되어야 합니다.
클라이언트 인증서를 생성하지 않고 클러스터를 만들려면 --no-issue-client-certificate
플래그를 사용하세요.
gcloud container clusters create CLUSTER_NAME --no-issue-client-certificate
현재까지는 기존 클러스터에서 클라이언트 인증서를 삭제할 수 있는 방법이 없습니다. 기존 클러스터에서 클라이언트 인증서 인증 사용을 중지하려면 클러스터에서 RBAC가 사용 설정되어 있고 클라이언트 인증서에 클러스터에 대한 승인이 없어야 합니다.
다음 단계
- Google Cloud 인증 알아보기
- GKE의 액세스 제어 알아보기
- Google 서비스 계정 알아보기
- 워크로드 아이덴티티 알아보기
- 클러스터 보안 강화 알아보기