ID 및 보안 구성

이 페이지에서는 사용자 클러스터에서 OpenID Connect(OIDC) 인증을 사용 설정하는 방법, 역할 기반 액세스 제어(RBAC)를 설정하는 방법, 인증에 Google 싱글 사인온(SSO)을 사용하는 방법을 설명합니다. OIDC를 사용한 인증에 대한 자세한 내용은 Anthos clusters on bare metal에서 OIDC를 사용한 ID 관리를 참조하세요.

사용자 클러스터에서 OIDC 인증 사용 설정

사용자 클러스터를 만드는 동안 또는 기존 사용자 클러스터에서 OIDC 인증을 사용 설정할 수 있습니다. OIDC 인증을 설정할 때의 전제조건은 클러스터에 적용할 ID 프로필이 존재해야 한다는 것입니다. ID 프로필 만들기를 참조하세요.

클러스터 만들기 중 ID 프로필 설정

클러스터 만들기 중 ID 프로필 적용

사용자 클러스터를 만드는 방법에 대한 자세한 내용은 관리 센터 UI를 통해 사용자 클러스터 만들기를 참조하세요. 클러스터 구성 페이지에서 사용자 클러스터를 만들려면 AIS 구성 드롭다운 목록에서 ID 프로필을 선택합니다. 이러한 ID 프로필은 사용자 클러스터에 적용됩니다.

기존 사용자 클러스터에 ID 프로필 설정

ID 및 액세스 페이지로 이동합니다.
클러스터에 프로필 적용을 클릭합니다.
프로필 드롭다운 목록에서 적용할 ID 프로필을 선택합니다.
클러스터 드롭다운 목록에서 ID 프로필을 적용할 클러스터를 선택합니다.

사용자 클러스터에 적용된 ID 프로필 보기

사용자 클러스터에 적용된 ID 프로필은 ID 및 액세스 페이지에서 볼 수 있습니다.

클러스터 탭을 선택하고, 확인할 사용자 클러스터를 찾은 후 해당 사용자 클러스터에 대해 구성 세부정보 보기를 클릭합니다.

사용자 클러스터 ID 구성 보기

사용자 클러스터 로그인 구성 다운로드

구성 세부정보 보기 슬라이드 아웃 페이지에서 로그인 구성 다운로드를 클릭합니다.

파일에서 OIDC 구성 지정

다음 콘텐츠가 포함된 파일을 만듭니다. 이 파일을 user-cluster-oidc-config.yaml로 저장합니다.

spec:
  authentication:
  - name: CONFIGURATION_NAME
    oidc:
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      # The URI to redirect users going through the OAuth flow using cloud
      # console.
      # This is a required parameter not supported by Anthos isolated mode, so
      # a dummy value is required.
      cloudConsoleRedirectURI: http://cloud.console.not.enabled
      extraParams: EXTRA_PARAMS
      issuerURI: ISSUER_URI
      # The redirect URL that kubectl uses for authorization.
      kubectlRedirectURI: http://localhost:9879/callback
      scopes: SCOPES
      userClaim: USER_CLAIM
      groupsClaim: GROUPS_CLAIM
      certificateAuthorityData: CERT_AUTHORITY_DATA

다음을 바꿉니다.

CONFIGURATION_NAME: 만들려는 OIDC 구성의 이름입니다.
CLIENT_ID: OpenID 제공업체에 인증을 요청하는 클라이언트 애플리케이션의 ID입니다.
CLIENT_SECRET: 클라이언트 애플리케이션의 보안 비밀입니다.
EXTRA_PARAMS: OpenID 제공업체에 전송할 추가적인 키-값 매개변수(쉼표로 구분)입니다.
ISSUER_URI: 승인 요청이 OpenID에 전송되는 URL입니다.
SCOPES: OpenID 제공업체에 전송할 추가 범위(쉼표로 구분)입니다.
USER_CLAIM: 사용자 이름으로 사용할 JWT 클레임입니다. OpenID 제공업체에 따라 이메일 또는 이름과 같은 다른 클레임을 선택할 수 있습니다. 하지만 이메일 이외의 클레임은 이름 충돌을 방지하기 위해 발급기관 URL이 프리픽스로 추가됩니다.
GROUPS_CLAIM: OIDC ID 토큰에서 사용자의 그룹 정보가 저장된 클레임의 이름입니다.
CERT_AUTHORITY_DATA: OIDC 제공업체에 대해 base64로 인코딩된 선택사항인 PEM 인코딩 인증서입니다. 필요하지 않으면 삭제합니다. 문자열을 만들려면 헤더를 포함한 인증서를 base64로 인코딩합니다. certificateAuthorityData에 결과 문자열을 단일 줄로 포함합니다.

원하는 구성으로 파일을 수정한 후 다음 명령어를 실행합니다.

kubectl patch --kubeconfig=USER_CLUSTER_KUBECONFIG clientconfig default -n kube-public \
  --type=merge --patch "$(cat OIDC_CONFIG)"

다음을 바꿉니다.

USER_CLUSTER_KUBECONFIG: 사용자 클러스터 Kubeconfig 파일의 경로입니다.
OIDC_CONFIG: 만든 구성 파일의 경로입니다.

사용자 클러스터에서 RBAC 설정

이 섹션에서는 개별 네임스페이스에 대해 액세스 권한을 부여하기 위해 RBAC를 설정하는 방법에 대한 예시를 제공합니다. 자세한 내용은 Kubernetes RBAC 문서를 참조하세요.

workload-a 및 workload-b라는 2개의 네임스페이스가 있다고 가정합니다. 네임스페이스 workload-a의 리소스를 사용자 alice@example.com이 읽고 쓸 수 있고 workload-b의 리소스를 사용자 bob@example.com이 읽을 수 있도록 하기 위해서입니다. alice@example.com은 workload-b에 액세스할 수 없고 bob@example.com은 workload-a에 액세스할 수 없습니다.

사용자 클러스터에서 네임스페이스를 만듭니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-a
kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG create namespace workload-b

각 네임스페이스에 대한 액세스를 제한하려면 각 네임스페이스에 대한 권한을 정의해야 합니다. Kubernetes에서는 역할을 만들어 이 작업을 수행할 수 있습니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-a
  name: a-full-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
EOF

foo-full-access에 대해 정의된 verbs는 이 역할이 네임스페이스에서 수행할 수 있는 모든 작업을 정의합니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: workload-b
  name: b-read-access
rules:
- apiGroups: [""] # Indicates the core API group.
  resources: ["*"] # This is a wildcard representing all resource types.
  verbs: ["get", "watch", "list"]
EOF

b-read-access의 경우 정의된 verbs는 역할이 리소스를 쿼리하는 것만 허용합니다.

사용자에게 권한을 부여하려면 RoleBindings를 만들어야 합니다. RoleBinding에는 개별 사용자뿐만 아니라 그룹도 포함될 수 있습니다. 이 예시에서는 개별 사용자를 보여줍니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: a-full-access-users
  namespace: workload-a
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: prefix-alice@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: a-full-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

위의 RoleBinding(a-full-access-users)은 사용자 alice@example.com에게 a-full-access 역할에 정의된 권한을 부여합니다. 즉, 사용자 alice@example.com은 workload-a 네임스페이스의 리소스를 읽고 쓸 수 있습니다.

kubectl --kubeconfig=USER_CLUSTER_KUBECONFIG apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: b-read-access-users
  namespace: workload-b
subjects:
# You can specify more than one subject
- kind: User
  # Using the userClaim 'email' in this example.
  # If the user prefix is 'prefix-', then prefix the username with the user
  # user prefix.
  name: bob@example.com # Replace this with an actual user.
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" specifies the binding to a Role / ClusterRole
  kind: Role # This must be Role or ClusterRole.
  name: b-read-access # This must match the name of the Role you wish to bind.
  apiGroup: rbac.authorization.k8s.io
EOF

이 RoleBinding(b-read-access-users)은 사용자 bob@example.com에게 b-read-access 역할에 정의된 권한을 부여합니다. 따라서 사용자 bob@example.com은 workload-b 네임스페이스의 리소스만 읽을 수 있습니다.

OIDC 제공업체로 로그인

사용자 클러스터의 관리자로서 사용자 클러스터의 모든 사용자가 로그인할 때 사용할 로그인 구성 파일을 가져옵니다. Anthos 비공개 모드 관리 센터 UI에서 로그인 구성을 가져오려면 사용자 클러스터 로그인 구성 파일 다운로드를 참조하세요. 또는 다음을 실행하여 로그인 구성 파일을 만들 수 있습니다.

actl auth create-login-config --kubeconfig=USER_CLUSTER_KUBECONFIG \
  --output=user-cluster-anthos-config.yaml

사용자 클러스터 사용자에게 user-cluster-anthos-config.yaml을 배포합니다.

OIDC 공급자로 인증하고 명령줄의 안내를 따르세요.

actl auth login --login-config=user-cluster-anthos-config.yaml \
  --cluster=USER_CLUSTER_NAME --kubeconfig=./user-cluster-oidc-kubeconfig

USER_CLUSTER_NAME을 관리 콘솔에 표시되는 사용자 클러스터의 이름으로 바꿉니다. --kubeconfig=user-cluster-oidc-kubeconfig는 출력 Kubeconfig 파일 이름입니다.

다음과 같이 kubectl을 사용하여 새 Kubeconfig를 사용합니다.

kubectl --kubeconfig=./user-cluster-oidc-kubeconfig get pods -A

Google SSO로 인증

격리 모드에서는 Google SSO를 사용할 수 없으며 이 섹션은 데모 및 테스트용으로만 사용됩니다. Google SSO를 사용하려면 클러스터와 브라우저가 Google의 SSO 서버에 연결할 수 있어야 합니다. Google의 SSO 서버는 사용자 클러스터에 연결할 필요가 없습니다.

Google Cloud Console에 로그인하고 적합한 프로젝트를 선택합니다.
'API 및 서비스 > OAuth 동의 화면' 섹션에 액세스합니다.
새 OAuth 동의 화면을 만듭니다. 이 정보는 일반적으로 사용자에게 표시됩니다.
1. 애플리케이션 홈페이지를 관리 URL로 설정합니다.
API 및 서비스 > 사용자 인증 정보 섹션에서 다음을 수행합니다.
1. 사용자 인증 정보 만들기를 클릭합니다.
2. 새 OAuth 클라이언트 ID를 만듭니다.
3. 애플리케이션 유형을 웹 애플리케이션으로 설정합니다.
4. 관련 이름을 선택합니다.
5. 자바스크립트 원본의 경우 https://anthos.example.com을 설정합니다. 여기서 https://anthos.example.com은 관리 센터의 도메인 이름입니다.
6. 승인된 리디렉션 URI의 경우 다음을 설정합니다.
  - https://anthos.example.com/_gcp_anthos_oidc_callback
  - http://localhost:9879/callback
클라이언트 ID 및 클라이언트 보안 비밀을 AdminUI 구성에 복사합니다.
OIDC 공급자 URL을 https://accounts.google.com으로 설정합니다.
Username Claim을 email로, Scopes를 openid email로 설정합니다.
추가 매개변수를 prompt=consent,access_type=offline으로 설정합니다. 그렇지 않으면 Kubernetes API 서버로 로그인할 수 없습니다.
플랫폼 관리자 권한을 부여할 사용자 이메일의 초기 목록(쉼표로 구분)을 추가합니다.
Save를 클릭합니다.

Google SSO

감사 로깅

Kubernetes 감사가 Anthos 비공개 모드에 대해 사용 설정되고, 플랫폼에서 관리 액세스 및 작업을 확인하기 위한 접근 방법을 제공합니다.

현재까지는 보관 기간, 새로고침 빈도, 청크 크기와 같은 매개변수에 대해 감사 로깅을 맞춤설정할 수 없습니다. 감사 수준은 Metadata입니다. 이 수준은 요청 메타데이터(요청 사용자, 타임스탬프, 리소스, 동사)를 로깅하지만 요청 또는 응답 본문을 로깅하지 않습니다.

감사 로깅은 기본적으로 Anthos 비공개 모드로 사용 설정됩니다. 감사 로그 액세스에 대한 세부 단계는 Logging 및 Monitoring을 참조하세요.