Bearer 토큰을 사용하여 인증

이 페이지에서는 Bearer 토큰을 사용하여 Google Cloud 외부에 등록된 클러스터에 로그인하여 인증을 설정하는 방법을 설명합니다. 설정 후 클러스터 관리자가 Google Cloud 콘솔에서 클러스터에 로그인할 수 있습니다. Kubernetes 인증에 지정된 다양한 종류의 Bearer 토큰이 지원됩니다. 가장 쉬운 방법은 클러스터에 Kubernetes 서비스 계정(KSA)을 만들고 해당 Bearer 토큰을 사용하여 로그인하는 것입니다.

기타 인증 방법

Bearer 토큰을 사용하여 인증을 설정하는 대신 조직의 요구에 따라 다음 인증 방법 중 하나를 설정할 수 있습니다.

  • Google ID: 사용자가 자신의 Google Cloud ID를 사용하여 로그인할 수 있습니다. 사용자가 이미 Google ID를 사용하여 Google Cloud에 액세스할 수 있으면 이 옵션을 사용합니다.

  • 클러스터가 OIDC ID 공급업체를 사용하도록 구성된 경우 이를 사용하여 Google Cloud Console에서 클러스터에 인증할 수 있습니다. 다음 가이드에서 GKE 클러스터에 OIDC를 설정하는 방법을 참조하세요.

    • OIDC로 GKE Identity Service용 클러스터 구성. 이 가이드에서는 모든 GKE 클러스터 유형에 대해 클러스터별로 OIDC 인증을 설정하는 방법을 설명합니다.
    • Fleet에 GKE Identity Service 설정 이 옵션을 사용하면 지원되는 클러스터 유형의 Fleet 수준에서 OIDC를 설정할 수 있습니다. Fleet 수준 설정은 Google Cloud의 GKE 클러스터, 모든 GKE 클러스터 유형, AWS의 EKS 연결 클러스터에 지원됩니다.

Google 제공 인증 방법이 조직에 적합하지 않으면 이 페이지의 안내에 따라 Bearer 토큰을 사용하여 인증을 설정합니다.

Google Cloud 콘솔을 통해 액세스를 위한 IAM 역할 부여

Google Cloud 콘솔을 사용하여 연결된 클러스터를 보려는 사용자에게는 최소한 다음 IAM 역할이 있어야 합니다.

  • roles/container.viewer. 사용자는 이 역할로 GKE 클러스터 페이지를 포함하여 Google Cloud 콘솔에서 컨테이너 리소스를 볼 수 있습니다. 이 역할에 포함된 권한에 대한 자세한 내용은 IAM 문서의 Kubernetes Engine 역할을 참조하세요.

  • roles/gkehub.viewer. 사용자는 이 역할로 Google Cloud 콘솔에서 Google Cloud 외부에 있는 클러스터를 볼 수 있습니다. Fleet에 Google Cloud 외부에 있는 클러스터가 포함되지 않으면 사용자에게 이 역할이 필요하지 않습니다. 이 역할에 포함된 권한에 대한 자세한 내용은 IAM 문서의 GKE 허브 역할을 참조하세요.

다음 명령어를 실행하여 이러한 역할을 부여합니다.

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/container.viewer
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member='user:EMAIL_ADDRESS' \
    --role=roles/gkehub.viewer

다음을 바꿉니다.

  • PROJECT_ID: Fleet 호스트 프로젝트의 프로젝트 ID입니다.

  • EMAIL_ADDRESS: 사용자의 Google Cloud 계정과 연결된 이메일 주소입니다.

IAM 역할 부여에 대한 자세한 내용은 IAM 문서의 프로젝트, 폴더, 조직 액세스 관리를 참조하세요.

역할 기반 액세스 제어 구성

클러스터에 대한 액세스는 Kubernetes 역할 기반 액세스 제어(RBAC)를 사용하여 제어됩니다.

각 사용자가 클러스터에 로그인할 수 있도록 사용자 또는 클러스터 관리자가 KSA를 만드는 것이 좋습니다. Bearer 토큰을 사용하는 것은 비밀번호를 사용하는 것과 비슷합니다. 따라서 각 사용자가 자신의 고유 계정을 가져야 합니다. KSA의 Bearer 토큰을 사용하여 로그인하면 모든 작업이 KSA로 실행되고 KSA에서 관리되는 RBAC 역할에 따라 제한됩니다.

KSA는 콘솔을 통해 액세스하기 위해 클러스터에 최소한 다음 RBAC 역할이 있어야 합니다.

cloud-console-reader RBAC 역할 만들기 및 적용

Google Cloud 콘솔에서 클러스터 리소스에 액세스하려는 인증된 사용자는 관련 Kubernetes 권한이 있어야 로그인할 수 있습니다. 이러한 사용자에게 클러스터 관리자와 같은 더 광범위한 권한을 부여하지 않으려면 클러스터의 노드, 영구 볼륨, 포드, 스토리지 클래스를 볼 수 있는 최소 권한이 포함된 커스텀 RBAC 역할을 만들 수 있습니다. 클러스터에 ClusterRole RBAC 리소스, cloud-console-reader를 만들어서 이 권한 집합을 정의할 수 있습니다.

cloud-console-reader는 사용자에게 클러스터의 노드, 영구 볼륨, 포드, 스토리지 클래스에 대한 get, list, watch 권한을 부여하여 관련 리소스에 대한 세부정보를 볼 수 있게 합니다.

kubectl

cloud-console-reader ClusterRole을 만들고 이를 클러스터에 적용하려면 다음 명령어를 실행합니다.

cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: cloud-console-reader
rules:
- apiGroups: [""]
  resources: ["nodes", "persistentvolumes", "pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
  resources: ["storageclasses"]
  verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml

그런 후 다음 섹션에 설명된 대로 이 역할을 KSA에 부여합니다.

KSA 만들기 및 승인

kubectl

KSA를 만들고 여기에 권한을 바인딩하려면 다음 단계를 따르세요.

  1. KSA 및 ClusterRoleBinding 리소스를 만들어 view 및 cloud-console-reader Kubernetes RBAC ClusterRoles를 KSA에 바인딩합니다.

    KSA_NAME=KSA_NAME
kubectl create serviceaccount ${KSA_NAME}
kubectl create clusterrolebinding VIEW_BINDING_NAME \
   --clusterrole view --serviceaccount default:${KSA_NAME}
kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
   --clusterrole cloud-console-reader --serviceaccount default:${KSA_NAME}

    다음을 바꿉니다.

    • KSA_NAME: KSA에 대해 선택하는 이름입니다.
    • VIEW_BINDING_NAME: view ClusterRoleBinding 리소스에 대해 선택하는 이름입니다. 원하는 대로 이름을 지정할 수 있지만 KSA에 따라 이름을 지정하는 것이 가장 쉽습니다.
    • CLOUD_CONSOLE_READER_BINDING_NAME: cloud-console-reader ClusterRoleBinding 리소스에 대해 선택하는 이름입니다. 이 이름도 원하는 대로 지정할 수 있습니다.

  2. 서비스 계정에 보유해야 하는 액세스 권한에 따라 KSA에 추가 역할을 바인딩합니다. 자세한 내용은 Kubernetes 기본 역할을 참조하세요.

    예를 들어 Cloud Marketplace에서 Kubernetes 애플리케이션을 배포하려면 cluster-admin 역할을 KSA에 바인딩합니다.

    kubectl create clusterrolebinding BINDING_NAME \
   --clusterrole cluster-admin --serviceaccount default:KSA_NAME

    BINDING_NAME을 서비스 계정의 클러스터 역할 결합 이름으로 바꿉니다.

다른 계정 승인

kubectl

클러스터에 대한 액세스 권한을 얻는 다른 모든 사용자 또는 서비스 계정은 ClusterRoleBinding 리소스를 만들어 계정에 view 및 cloud-console-reader 역할을 바인딩합니다.

  1. view 및 cloud-console-reader ClusterRoles를 바인딩합니다.

    ACCOUNT_NAME=ACCOUNT_NAME
kubectl create clusterrolebinding VIEW_BINDING_NAME \
   --clusterrole view --serviceaccount default:${ACCOUNT_NAME}
kubectl create clusterrolebinding CLOUD_CONSOLE_READER_BINDING_NAME \
   --clusterrole cloud-console-reader --serviceaccount default:${ACCOUNT_NAME}

    다음을 바꿉니다.

    • ACCOUNT_NAME: Kubernetes 서비스 계정입니다.
    • VIEW_BINDING_NAME: view ClusterRoleBinding 리소스에 대해 선택하는 이름입니다. 원하는 대로 이름을 지정할 수 있지만 사용자 또는 서비스 계정에 따라 이름을 지정하는 것이 가장 쉽습니다.
    • CLOUD_CONSOLE_READER_BINDING_NAME: view ClusterRoleBinding 리소스에 대해 선택하는 이름입니다. 이 이름도 원하는 대로 지정할 수 있습니다.

  2. 계정에 필요한 액세스 권한에 따라 추가 역할을 바인딩합니다. 자세한 내용은 Kubernetes 기본 역할을 참조하세요.

    예를 들어 cluster-admin 역할을 바인딩하려면 다음 명령어를 실행합니다.

    kubectl create clusterrolebinding BINDING_NAME \
   --clusterrole cluster-admin --serviceaccount default:ACCOUNT_NAME

    BINDING_NAME을 서비스 계정의 클러스터 역할 결합 이름으로 바꿉니다.

KSA의 Bearer 토큰 가져오기

kubectl

KSA의 Bearer 토큰을 획득하려면 다음 명령어를 실행합니다.

SECRET_NAME=KSA_NAME-token

kubectl apply -f - << __EOF__
apiVersion: v1
kind: Secret
metadata:
  name: "${SECRET_NAME}"
  annotations:
    kubernetes.io/service-account.name: "${KSA_NAME}"
type: kubernetes.io/service-account-token
__EOF__

until [[ $(kubectl get -o=jsonpath="{.data.token}" "secret/${SECRET_NAME}") ]]; do
  echo "waiting for token..." >&2;
  sleep 1;
done

kubectl get secret ${SECRET_NAME} -o jsonpath='{$.data.token}' | base64 --decode

KSA_NAME을 KSA에 대해 선택하는 이름으로 바꿉니다.

이 명령어의 출력에서 사용자가 토큰을 사용하여 Google Cloud Console에 로그인할 수 있도록 토큰을 복사하고 저장합니다.