Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

IAM으로 리소스 액세스 보안

Kubernetes 사용자 및 서비스 계정에는 구성 커넥터 리소스를 관리할 수 있는 권한이 필요합니다. 구성 커넥터를 사용하면 Kubernetes 역할 기반 액세스 제어(RBAC)를 사용하는 ID로 프로젝트의 컨트롤 플레인을 관리할 수 있습니다. Identity and Access Management(IAM) 정책을 참조할 수도 있습니다.

IAMPolicy 및 IAMPolicyMember를 참조할 수 있는 리소스는 리소스 참조에 나열되어 있습니다. 이러한 리소스에는 'IAMPolicy/IAMPolicyMember에서 참조할 수 있는' 속성이 있습니다.

이 주제에서는 Identity and Access Management를 사용하여 Google Cloud 리소스에 대한 액세스를 보호하는 방법을 설명합니다.

시작하기 전에

클러스터에 구성 커넥터를 설치합니다.

RBAC를 통한 컨트롤 플레인 액세스 보안

이 예시에서는 서비스 계정을 만들고 PubSubTopic을 관리할 수 있는 권한을 부여합니다. 이 서비스 계정은 다른 유형의 구성 커넥터 리소스를 관리할 수 없습니다.

다음 콘텐츠로 pubsub-topic-service-account.yaml이라는 파일을 만듭니다.
```
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pubsub-topic-service-account
  namespace: default
```
pubsub-topic-service-account 서비스 계정을 만들려면 다음을 적용합니다.
```
kubectl apply -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE
```
CC_NAMESPACE를 구성 커넥터가 관리하는 리소스의 네임스페이스로 바꿉니다.
다음 명령어의 결과에 no이 있는지 살펴서 pubsub-topic-service-account으로 PubSubTopic 리소스를 만들 수 없음을 확인합니다.
```
kubectl auth can-i get pubsubtopics --as=system:serviceaccount:default:pubsub-topic-service-account
```
그 다음으로 Pub/Sub 주제 만들기를 허용하는 ClusterRole를 생성합니다.

ClusterRole은 rules.apiGroups 및 rules.resources에 지정된 값이 있는 리소스만 관리할 수 있습니다. apiGroups 및 resources의 값을 찾으려면 리소스의 참조를 확인하세요.

다음 콘텐츠로 pubsub-topic-editor-role.yaml라는 파일을 만듭니다.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: pubsub-topic-editor
rules:
- apiGroups:
  - pubsub.cnrm.cloud.google.com
  resources:
  - pubsubtopics
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
```
pubsub-topic-editor.yaml을 적용하여 ClusterRole을 만듭니다.
```
kubectl apply -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE
```
CC_NAMESPACE를 구성 커넥터가 관리하는 리소스의 네임스페이스로 바꿉니다.

다음으로 ClusterRole과 서비스 계정 사이에 RoleBinding을 만듭니다. 다음 콘텐츠로 pubsub-topic-editor-rolebinding.yaml이라는 파일을 만듭니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pubsub-topic-editor-rolebinding.
subjects:
- kind: ServiceAccount
  name: pubsub-topic-service-account
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pubsub-topic-editor

클러스터에 pubsub-topic-editor-rolebinding.yaml을 적용합니다.
```
kubectl apply -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE
```
CC_NAMESPACE를 구성 커넥터가 관리하는 리소스의 네임스페이스로 바꿉니다.
다음 명령어의 결과가 yes인지 살펴서 pubsub-topic-service-account으로 PubSubTopic 리소스를 만들 수 있음을 확인합니다.
```
kubectl auth can-i get pubsubtopics \
  --as=system:serviceaccount:default:pubsub-topic-service-account
```

삭제

kubectl delete를 사용하여 서비스 계정, IAM 역할 및 Rolebinding을 제거합니다.

kubectl delete -f pubsub-topic-editor-rolebinding.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-editor-role.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-service-account.yaml --namespace CC_NAMESPACE

CC_NAMESPACE를 구성 커넥터가 관리하는 리소스의 네임스페이스로 바꿉니다.

IAM 정책으로 데이터 영역 보안

이 예시에서는 이전에 부여된 권한을 사용하여 PubSubTopic을 만들고 IAMPolicyMember 리소스로 액세스를 제한합니다.

다음 콘텐츠로 pubsub-topic-sample.yaml이라는 파일을 만듭니다.
```
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: pubsubtopic-sample
```
kubectl로 pubsub-topic-sample.yaml을 적용합니다.
```
kubectl apply -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE
```
CC_NAMESPACE를 구성 커넥터가 관리하는 리소스의 네임스페이스로 바꿉니다.

다음 콘텐츠로 iampolicymember.yaml이라는 파일을 만들고 EMAIL_ADDRESS를 Google Cloud 계정의 이메일 주소로 바꿉니다.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: iampolicymember-sample
spec:
  resourceRef:
    apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
    kind: PubSubTopic
    name: pubsubtopic-sample
  role: roles/pubsub.admin
  member: "user:EMAIL_ADDRESS"

iampolicymember.yaml을 적용합니다.
```
kubectl apply -f iampolicymember.yaml  --namespace CC_NAMESPACE 
```
CC_NAMESPACE를 구성 커넥터가 관리하는 리소스의 네임스페이스로 바꿉니다.
다음 명령어를 실행하고 출력에서 이메일 주소를 찾아 정책이 Google Cloud 에 적용되었는지 확인합니다. 여기서 PROJECT_ID는 프로젝트 ID로 바꿉니다.
```
gcloud beta pubsub topics get-iam-policy projects/PROJECT_ID/topics/pubsubtopic-sample
```

Pub/Sub 주제에 대한 액세스가 이제 IAMPolicyMember로 보호됩니다.

삭제

kubectl delete를 사용하여 Google Cloud 프로젝트에서 Pub/Sub 주제 및 IAMPolicyMember를 삭제합니다.

kubectl delete -f iampolicymember.yaml --namespace CC_NAMESPACE
kubectl delete -f pubsub-topic-sample.yaml --namespace CC_NAMESPACE

멀티테넌트 격리를 위한 보안 권장사항

무단 권한 에스컬레이션을 방지하고 테넌트 격리를 적용하려면 다음 권장사항을 따르세요.

네임스페이스 모드 적용: 멀티 테넌트 환경에서 클러스터 모드를 사용하지 않습니다. 클러스터 모드에서는 모든 네임스페이스가 단일 IAM 서비스 계정을 공유합니다. 네임스페이스에서 구성 커넥터 리소스를 만들 수 있는 모든 사용자는 해당 서비스 계정의 전체 IAM 권한으로 작업할 수 있습니다.
IAM 리소스에 대한 RBAC 제한: Kubernetes 역할 기반 액세스 제어(RBAC)를 사용하여 IAMPolicy, IAMPartialPolicy, IAMPolicyMember 리소스의 생성 및 수정 권한을 제한합니다. 개발자가 이러한 리소스에 대한 광범위한 쓰기 액세스 권한을 가지고 있으면 Google Cloud IAM 바인딩을 변경할 수 있습니다.
GKE용 워크로드 아이덴티티 제휴의 IAM 바인딩 범위 지정: 특정 네임스페이스의 지정된 Kubernetes ServiceAccount에 대해 엄격하게 이러한 바인딩을 구성합니다. 네임스페이스 모드에서 각 IAM 서비스 계정을 해당 네임스페이스의 구성 커넥터 Kubernetes ServiceAccount에만 바인딩합니다.
```
gcloud iam service-accounts add-iam-policy-binding \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member="serviceAccount:PROJECT_ID.svc.id.goog[cnrm-system/cnrm-controller-manager-CC_NAMESPACE]" \
    --role="roles/iam.workloadIdentityUser"
```
다음을 바꿉니다.
- GSA_NAME: 구성 커넥터가 네임스페이스에 사용하는 IAM 서비스 계정의 이름입니다.
- PROJECT_ID: 클러스터와 IAM 서비스 계정이 포함된 프로젝트의 ID입니다.
- CC_NAMESPACE: 구성 커넥터가 리소스를 관리하는 네임스페이스입니다.
cnrm-system 네임스페이스의 모든 포드와 같은 주 구성원 집합에 roles/iam.workloadIdentityUser 역할을 부여하지 마세요. 네임스페이스 모드에서 모든 네임스페이스의 구성 커넥터 컨트롤러는 cnrm-system에서 실행되므로 이 유형의 바인딩을 사용하면 모든 네임스페이스의 컨트롤러가 IAM 서비스 계정을 가장할 수 있습니다.

다음 단계

보안 비밀을 사용하여 정보를 Google Cloud 리소스에 안전하게 전달합니다.