EKS Cluster의 Service Account에 IAM Role을 부여 = IRSA(IAM Roles for Service Accounts)
완벽하지는 않지만 공식 홈페이지와 다른 블로그를 참조해서 정리를 해보았다.
쿠버네티스에서 요구 사항에 맞는 IAM 역할을 생성할 수 있다. -> Pod 수준에서 세분화된 역할을 생성하여 최소 권한의 보안 원칙을 가능하게 한다. -> 클러스터에 대한 IAM OIDC 공급자를 연결 = 클러스터에는 OIDC 발급자 URL이 이미 존재
각 EKS Cluster 마다 가지고 있는 전용 OIDC Identity Provider를 나타낸다. AWS IAM에게 신뢰하는 OIDC Identity Provider로 등록(Federate)되어 있다. -> 클러스터를 생성하면 OIDC 인증기관 주소가 함께 생성되어 제공이 된다.
해당 주소를 이용해서 Provider를 생성할 수 있다.
IAM 역할을 생성하고 역할을 쿠버네티스 서비스 계정과 연결한다.
eksctl create iamserviceaccount --name {serviceaccount 이름} --namespace {서비스 계정을 생성할 네임스페이스} --cluster {클러스터 이름} --role-name {IAM Role 이름} \
--attach-policy-arn arn:aws:iam::{계정 ID}:policy/{적용하려는 정책 이름} --approve정상적으로 서비스 어카운트가 생성이 되면 결과물에 oidc.eks라는 결과가 Condition에 나타난다.
또한 쿠버네티스 서비스 계정에 역할이 annotaions로 달린다.
Private/ Public Key : AWS EKS OIDC provider와 쿠버네티스 API 서버는 동일한 Key를 공유하게 된다.
Pod Identity Webhook : API 서버로 요청을 보내면 API 서버가 Mutating Webhook에 요청 Pod가 IAM Role을 가진 Service Accout를 이용하는 경우 Pod 내부에서 Service Account에 부여된 IAM Role을 이용할 수 있도록 Spec을 변경한다.
Mutating Webhook?
쿠버네티스는 접근 제어를 3단계로 진행한다. 1 Authentication(인증) 2. Authorization(인가) 3. Admission Control(?)
Admission Control : 인증과 인가를 통과한 사용자에 한해서 Admin이 추가로 특정 행동을 제한 혹은 변경하는 작업 -> 세부 작업에 대한 지침 사항 이때 2단계를 걸쳐서 제한, 변경이 되는데 Mutata, Validate이다.
Mutata
사용자가 요청한 매니페스트를 검사해 적절한 값으로 수정하는 변형 작업
Validate
매니페스트가 유효한지 검사 함으로써 요청을 거절 할것인지 결정한다.
쿠버네티스 특징으로 API로 통신이 되는데 Webhook으로 Admission Control을 동작 시킬 수 있다.
MutatingWebhook : 사용자가 요청한 Req에 대해서 관리자가 임의로 값을 변경하는 작업 ValidatingWebhook : 사용자가 요청한 Req에 대해 관리자가 허용을 막는 작업-> 인증, 인가를 통과한 후 Mutat 한 뒤 변경된 내용을 Validate (검증) 후 etcd에 저장 후 작업이 이어진다.
Projected SA Token : IAM Role이 부여된 Service Account의 Token을 나타낸다.(K8s의 Service Account Token과 별개의 Token) = JWT 형태
Projected SA Token가 Pod에 있어도 AssumeRoleWithWebIdentity(임시 보안 자격 증명)을 사용하기 위해서는 OIDC의 정보를 담은 JWT Token이 필요하다. 원래라면 OIDC의 ID Token(인가를 위한)이 필요한데 API 서버가 OIDC의 Private/ Public key를 가지고 있어서 직접 JWT Token을 생성해서 Pod에 주입한다.
IAM Role 부여 과정
0. EKS 클러스터의 OIDC Provider를 생성해 Private/ Public Key를 Provider와 K8s API Server가 공유한다.
1. eksctl을 이용해서 iamserivice account를 생성한다. "eksctl create iamserviceaccount"
2. Pod를 생성 할 때 service account를 넣어서 생성한다. (aws lb controller 를 배포 할떄 포함되어 있다)
3. K8s API 서버로 Pod 생성요청을 보내면 API 서버가 serviceaccount를 확인해 Pod Identity Webhook에 의해 강제로 Pod에 '부여 받는 AWS IAM Role, JWT Token의 위치, 클러스터 리전 정보'가 주입 된다. = Spec Mutate
JWT Token의 위치는 aws-iam-token 이름의 Projected SA Token Volume을 생성하고 Mount하도록 만들고 Projected SA Token으로 저장된다. (만료시간, Audience 설정도 포함)
3-1. Token을 바로 Pod에 저장될 때 API 서버에게 SA Token을 요청하고 받아서 Pod에 Projected SA Token을 저장한다.
4. Mutate된 Pod 생성 Req를 Kubelet에 API 서버가 보내서 kubelet이 Pod를 생성한다.
5. Pod가 AWS STS/IAM에게 Projected SA Token의 credential(자격증명)을 요청 하면 AWS STS/IAM은 AWS EKS OIDC Provider에게 검증을 하는데 Projected SA Token은 같은 키를 가진 API 서버가 만든 Token 이어서 검증을 성고해 자격증명을 허락한다.
6. 허락된 Pod는 AWS 리소스에 접근 및 사용 권한을 가지고 요청이 가능해진다.
Working with EKS: Using IAM and native K8s service accounts to access AWS S3
This post looks at how a native K8s service account can be used along with an IAM role as a strategy...
dev.to
Cross account IAM roles for Kubernetes service accounts | Amazon Web Services
With the introduction of IAM roles for services accounts (IRSA), you can create an IAM role specific to your workload’s requirement in Kubernetes. This also enables the security principle of least privilege by creating fine grained roles at a pod level i
aws.amazon.com
AWS EKS Service Account에 AWS IAM Role 부여
AWS EKS Cluster의 Service Account에 AWS IAM Role을 부여하는 과정을 정리한다. 이러한 기능을 IRSA(IAM Roles for Service Accounts)라고 명칭한다.
ssup2.github.io
'경기도 미래기술학교 클라우드 > TIL' 카테고리의 다른 글
| EKS와 OIDC (1) | 2023.10.04 |
|---|---|
| 23.09.25 AWS 컨테이너 CICD #3 (0) | 2023.09.25 |
| 23.09.23 AWS SAA-C03 합격 후기 (0) | 2023.09.23 |
| 23.09.22 AWS 컨테이너 CICD #2 (0) | 2023.09.22 |
| 23.09.21 AWS 컨테이너 CICD #1 (0) | 2023.09.21 |
