[GCP] Cloud 관리형 계정&role

현재 근무하고 있는 사이트는 GCP 기반이다 보니 GCP 에 대해서 많은 지식을 쌓고 있는 중이다.

그러다 몇가지 이슈가 생겨서 글을 작성 해보도록 하겠다.

현재 사이트는 role / policy / user , group 관리를 아주 세세하고 디테일 한 부분까지 다 염두 해두고 관리 중이다.

어느날 composer(GKE-Google Kubernetes Engine) 를 설치 하던 도중 service agent 구성을 해야 한다는 메세지가 보였다.

그래서 일전에 작성한 글을 기반으로 ServiceAgent가 왜 필요한지에 대해서 나름대로 고민해본 내용을 공유 하려 한다.

팀 내부에서는 우리가 이미 설치에 필요한 모든 role을 부여한 ServiceAccount 계정이 있는데 왜 ServiceAgent(다른 이야기로 하면 google 관리형 account)가 필요한지 의문이 생겼다.

ServiceAgent란? https://cloud.google.com/iam/docs/create-service-agents?hl=ko

Google Cloud에서 프로젝트 수준, 폴더 수준, 조직 수준의 서비스 에이전트는 
Google Cloud 서비스를 사용 설정하고 사용할 때 자동으로 생성됩니다. 
경우에 따라 이러한 서비스 에이전트에는 사용자 대신 리소스를 만들고 액세스할 수 있게
해주는 역할이 자동으로 부여됩니다.
필요에 따라 서비스를 사용하기 전 Google Cloud에 서비스에 대해 
프로젝트 수준, 폴더 수준, 조직 수준 서비스 에이전트를 만들도록 요청할 수도 있습니다. 
Google Cloud에 서비스 에이전트를 만들도록 요청하면 서비스 사용 전 서비스 에이전트에 역할을 부여할 수 있습니다. 
서비스 에이전트가 아직 생성되지 않았으면 서비스 에이전트에 역할을 부여할 수 없습니다.

이 옵션은 허용 정책 관리를 위해 다음 전략 중 하나를 사용할 때 유용합니다.
Terraform과 같은 선언적 프레임워크. Terraform 구성에 서비스 에이전트 역할이 포함되지 않은 경우 
구성을 적용할 때 해당 역할이 취소됩니다. 
Terraform 구성에서 서비스 에이전트를 만들고 여기에 역할을 부여하면 해당 역할이 취소되지 않습니다.
코드 저장소에 현재 허용 정책의 사본을 저장하는 코드형 정책 시스템. 
Google Cloud가 서비스 에이전트에 자동으로 역할을 부여하도록 설정하면 해당 역할이 실제 허용 정책에 표시되지만
저장된 허용 정책 사본에는 표시되지 않습니다. 
이러한 불일치를 해결하기 위해 이러한 역할을 잘못 취소할 수 있습니다. 
서비스 에이전트를 만들고 여기에 역할을 미리 부여하면 코드 저장소와 
실제 허용 정책 간의 차이를 방지하는 데 도움이 될 수 있습니다.
서비스 에이전트 만들기를 트리거한 후에는 일반적으로 자동으로 부여되는 역할을 서비스 에이전트에 부여해야 합니다. 
그렇지 않으면 일부 서비스가 올바르게 작동하지 않을 수 있습니다.
이것은 사용자 요청으로 생성된 서비스 에이전트에 권한이 자동으로 부여되지 않기 때문입니다.

AWS EKS에서는 아래와 같이 표현한다.

기본적으로 IAM 사용자 및 역할은 Amazon EKS 리소스를 생성하거나 수정할 수 있는 권한이 없습니다.
또한 AWS Management Console, AWS CLI또는 AWSAPI를 사용해 태스크를 수행할 수 없습니다.
IAM 관리자는 지정된 리소스에서 특정 API 태스크를 수행할 수 있는 권한을 사용자와 역할에게 부여하는 IAM 정책을 생성해야 합니다.
그런 다음 관리자는 해당 권한이 필요한 IAM 사용자 또는 그룹에 이러한 정책을 연결해야 합니다.

이러한 예제 JSON 정책 문서를 사용하여 IAM ID 기반 정책을 생성하는 방법을 알아보려면
IAM 사용 설명서의 JSON 탭에서 정책 생성을 참조하세요.

Amazon EKS 클러스터를 생성할 경우 클러스터를 생성하는 IAM 보안 주체에게는 Amazon EKS 제어 영역의 클러스터
역할 기반 액세스 제어(RBAC) 구성에 system:masters 권한이 자동으로 부여됩니다.
이 보안 주체는 표시되는 구성에 나타나지 않으므로 클러스터를 원래 생성한 보안 주체를 추적해야 합니다.
추가 IAM 보안 주체에 클러스터와 상호 작용할 수 있는 기능을 부여하려면 
Kubernetes 내에서 aws-auth ConfigMap을 편집하고
aws-auth ConfigMap에 지정하는 group의 이름으로 Kubernetes rolebinding 또는 clusterrolebinding을 생성합니다.

그래 설명은 알겠다. iac/api 로 설치를 하는데 있어서는 필요하다고 쳐도 그럼 왜 일반 관리형 서비스계정으로는 설치가 안되는것인가? 에 대한 의문은 아직 해소 되지 않았다.

https://dorian.gitbook.io/devops/kubernetes/eks/eks-csr 를 보면 설치 시 사용한 계정과 실제 서비스 구동에 필요한 iam 을 동일하게 사용 했을 경우

쿠버네티스 인증서 발급이 안된다.

위의 예는 직접 경험해본 하나의 예시만 이야기를 해봤지만 대부분의 jwt token 방식으로 인증 / 인가를 하는 솔루션들은 모두 유사한 문제가 있기 때문에

AWS는 AWS 관리형 정책 이라는 이름으로 GCP는 ServiceAgent(Google 관리형 ServiceAccount)는 이름으로 별도 관리를 하는 것으로 추측 된다.

그렇기 때문에 AWS 는 설치 role과 node role , sa role 의 별도 생성 GCP는 설치 시 ServiceAgent 실제 role부여는 사용자생성ServiceAccount를 이용한다.

이런걸 보면 결국 Cloud 벤더는 다르지만 쿠버네티스와 CSR , X509 인증서 정책은 모두 같은 아키텍처를 기반으로 하고 있기 때문에 비슷한 정책이 나온게 아닌가 싶다.