[Kubernetes] IRSA 인증부터 갱신까지 쭈욱~

 

이번 글의 주제인 "IRSA" 는 이해하기도 힘들었지만, 이걸 글로 작성하는 건 더 어려워서 많은 블로그 글들과 강의를 참고했습니다.

틀린 부분이 있을 수 있으며, 아래에 명시한 참고 블로그들도 읽어주세요!

 

 

IRSA 는 IAM Roles for Service Account 의 약자로, Kubernetes 에서 AWS 리소스에 안전하게 접근할 수 있도록 하기 위한 메커니즘입니다.

 

IRSA 를 사용하면 쿠버네티스 클러스터 내의 특정 Service Account 에 AWS IAM Role 을 매핑할 수 있습니다. 이를 통해 해당 Service Account 이 AWS 리소스에 접근할 수 있는 권한을 얻습니다. 

 

IRSA 는 AWS 에서 제공하는 OIDC 와 IAM Role 을 사용하여 쿠버네티스 파드가 AWS 자격 증명을 직접 관리할 필요 없이 AWS 리소스에 접근할 수 있게 해줍니다.

 

그럼 간단히 IRSA 에 대해 알아봤으니, 실제로 어떻게 동작하는지 알아보도록 하겠습니다!

 

To the Code~!

 

 

Shallow Dive

---

우선 IRSA 을 어떻게 적용하는지부터 살펴보죠!

 

serviceaccount 와 pod 를 아래와 같이 배포해줘야 하는데,

apiVersion: v1
kind: ServiceAccount
automountServiceAccountToken: true
metadata:
  name: irsa-exam
  annotations:
    eks.amazonaws.com/role-arn: "arn:aws:iam::xxxx:role/IRSA_Exam"
---
kind: Pod
apiVersion: v1
metadata:
  name: irsa-exam
spec:
  serviceAccountName: irsa-exam
  containers:
    - name: aws
      image: amazon/aws-cli
      command: [ "/bin/sh" ]
      args: [ "-c", "while true; do echo hello; sleep 1d;done" ]

 

serviceaccount 에 명시할 IAM Role 의 ARN 이 현재 없으니 만들어 줍시다.

 

IRSA 용 IAM Role 은 직접 만들 수도 있지만, Terraform IAM Module 을 이용하면 편하게 만들 수 있습니다.

 

https://github.com/terraform-aws-modules/terraform-aws-iam/blob/master/examples/iam-role-for-service-accounts-eks/main.tf#L32-L54

기본 IRSA 말고도 많이 사용하는 네이티브 앱들에 대한 IRSA 도 제공해주니 이용하면 굉장히 편합니다.
cert_manager_irsa_role, karpenter_controller_irsa_role 등

 

Terraform IAM Module 를 통해 Role 을 생성했다면, 신뢰 관계(Trust Relationships) 를 한번 확인해봅니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ExplicitSelfRoleAssumption",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "ArnLike": {
                    "aws:PrincipalArn": "arn:aws:iam::xxxx:role/IRSA_Exam"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::xxxx:oidc-provider/oidc.eks.ap-northeast-2.amazonaws.com/id/xxxx"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "oidc.eks.ap-northeast-2.amazonaws.com/id/xxxx:sub": "system:serviceaccount:default:irsa-exam",
                    "oidc.eks.ap-northeast-2.amazonaws.com/id/xxxx:aud": "sts.amazonaws.com"
                }
            }
        }
    ]
}

 

핵심만 살펴보면 해당 ARN 을 가진 OIDC Provider 는 sts:AssumeRoleWithWebIdentity 를 수행할 수 있습니다. 다만 subject 가 system:serviceaccount:default:irsa-exam 가 이여야 하고, audience 가 sts.amazonaws.com 이여야 합니다.

 

추가로 "oidc.eks.ap-northeast-2.amazonaws.com/id/xxxx:sub" 부분의 "system:serviceaccount:default:irsa-exam" 은 반드시 Service Account 의 네임스페이스와 이름과 일치해야 합니다.

StringEquals 말고 StringLike 를 통해 * 사용 또한 가능하지만, 추천드리지는 않습니다.

 

이후 파드에 접근하여 aws s3 ls 와 같은 명령어를 실행하면 AWS 리소스에 접근하는 것을 확인할 수 있습니다.

참고로 파드 내에서 WebIdentityToken 을 지원해주어야 가능합니다.

 

IRSA 가 동작하는지만 확인하려면 여기까지 진행해도 전혀 문제 없지만, 저는 이 동작 안에서 궁금한 점이 2가지 존재했습니다.

1. ServiceAccount 에 Annotation 만 달았는데 어떻게 해당 ServiceAccount 를 마운트한 파드에서 AWS 에 접근이 가능하지?
2. ServiceAccount 는 JWT 형태로 토큰을 가지고 있는데 만료가 되었을 경우 어떻게 갱신하지?

IRSA 에 대해 조금 더 깊이있게 들어가보면서 해당 궁금점을 바로 해소해보죠!

 

Deep Dive

---

ServiceAccount 에 단순히 Annotation 을 작성하는 것만으로도 AWS 에 접근을 가능케 해주는(Assume Role 에 필요한) JWT 를 얻을 수 있다는 것을 알았습니다. 그런데 이 JWT 는 갑자기 어디서 튀어 나왔을까요?

여기서 말하는 JWT 는 K8S SA Token 을 의미하며, 실질적으로 Assume Role 에 필요한 Token 을 말합니다.
AWS 리소스에 접근하는 AWS Session Token 과는 다릅니다. 지금은 이해가 안가시더라도 글을 다 읽은 후에는 이해가 되실겁니다!

 

 

쿠버네티스한테 명령을 할 때, 기본적으로 API Server 에 요청을 보내게 됩니다. 요청은 받은 API Server 는 아래 그림과 같은 과정을 거치게 됩니다.

https://sysdig.com/blog/kubernetes-admission-controllers/

 

여기서 Mutating Admission 과 Validating Admission 을 합쳐 Admission Controller 라고 부릅니다.

Mutating Admission 에선 요청한 매니페스트를 변경해주고, Validating Admission 은 최종 매니페스트가 유효한 매니페스트인지 판단을 해주죠.

더 자세하게 알고 싶다면 인증/인가와 ECTD 사이 그 녀석 - Admission Controller 를 참고해주세요!

 

우리는 이 Mutating Admission 과정을 통해서 Assume Role 에 필요한 JWT 을 얻을 수 있는 것이지요!

 

Mutating Admission 은 쿠버네티스 내에서 mutatingwebhookconfigurations.admissionregistration.k8s.io 로 정의됩니다.

 

그래서 아래 명령어를 실행하면, 관련한 리소스를 확인할 수 있습니다.

$ kubectl get mutatingwebhookconfigurations.admissionregistration.k8s.io

pod-identity-webhook

 

매니페스트를 살펴보면, 

pod-identity-webhook

 

pods 라는 리소스가 CREATE 될 때 해당 Admission 이 실행되는 것을 확인할 수 있습니다. 이후 https://127.0.0.1:23443/mutate 엔드포인트로 해당 파드의 정보를 보내게 됩니다.

 

여기서 https://127.0.0.1:23443/mutate 은 amazon-eks-pod-identity-webhook 의 엔드포인트를 가리키는 것 같은데, kubectl get 으로 보이지 않는 것으로 보아 쿠버네티스 위에 있는거 같진 않습니다.

 

이거는 뇌피셜인데, Control Plane 에 amazon-eks-pod-identity-webhook 라는 단독 애플리케이션으로 존재하는 것으로 추측됩니다. 그렇기 때문에 API Server 에서 로컬 주소인 127.0.0.1:23443 로 요청을 보낼 수 있다고 생각합니다.

 

https://aws.amazon.com/ko/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/

 

건드린다면 클러스터에 큰 장애를 일으킬 수 있기 때문에 Control Plane 처럼 AWS 가 직접 관리하는 것 같습니다.

혹시 관련되서 아는 정보가 있다면 알려주세요! 관련된 오피셜한 정보를 찾을 수가 없네요 ㅜㅜ

 

아무튼 https://127.0.0.1:23443/mutate 을 거쳐 변형된 파드 매니페스트가 실질적으로 쿠버네티스에 배포됩니다.

 

변형되었다고 해서 격변한 부분은 없습니다. 그저 ENV 와 마운트볼륨만 추가되었습니다.

 

아래 매니페스트는 Webhook 으로 인해 변형된 부분만 작성하였습니다.

 ...
    env:
    - name: AWS_STS_REGIONAL_ENDPOINTS
      value: regional
    - name: AWS_DEFAULT_REGION
      value: ap-northeast-2
    - name: AWS_REGION
      value: ap-northeast-2
    - name: AWS_ROLE_ARN
      value: arn:aws:iam::xxxx:role/IRSA_Exam
    - name: AWS_WEB_IDENTITY_TOKEN_FILE
      value: /var/run/secrets/eks.amazonaws.com/serviceaccount/token
 ...
    volumeMounts:
    - mountPath: /var/run/secrets/eks.amazonaws.com/serviceaccount
      name: aws-iam-token
      readOnly: true
  ...
  volumes:
  - name: aws-iam-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.amazonaws.com
          expirationSeconds: 86400
          path: token

volumes 를 보면 projected 라고 되어있는데, 이 기능은 쿠버네티스 1.12 에서 추가된 projectedServiceAccountToken 이라는 기능으로 토큰에 exp, aud 등의 속성을 추가할 수 있습니다.

이 기능이 지원되기 이전에는 직접 넣어줬어야 했습니다.

 

그리고 /var/run/secrets/eks.amazonaws.com/serviceaccount/token 경로에 Assume Role 에 사용할 JWT 가 존재합니다.

k8s sa token

 

그럼 /var/run/secrets/eks.amazonaws.com/serviceaccount/token 에 있는 k8s sa token 으로 뭘 할 수 있을까요?

바로 AWS 리소스에 접근이 가능한 AWS Session Token 를 얻을 수 있습니다. (Assume Role 에 리소스 접근 권한이 있어야함)

#-- /run/secrets/eks.amazonaws.com/serviceaccount 에 있는 token 값
$ IRSA_TOKEN="<JWT>"

$ aws sts assume-role-with-web-identity \
    --role-arn arn:aws:iam::xxxx:role/IRSA_Exam \
    --role-session-name test \
    --web-identity-token $IRSA_TOKEN

 

위 명령어를 보면 $IRSA_TOKEN 에 k8s sa token 을 넣어주어 AWS Session Token 값을 얻을 수 있습니다. 

AWS Session Token

 

눈치를 채셨을 분도 있을 수 있겠지만, k8s sa token 을 얻어내기만 한다면 만료되기 전까지 어디서든 해당 k8s sa token 을 통해 AWS Session Token 을 얻을 수 있습니다. 

 

따라서 k8s sa token 이 노출된다면, 해당 토큰을 통해 IRSA_Exam Role 인것처럼 위장할 수 있다는 위험이 있을 수 있습니다.

그렇기에 늘 k8s sa token 은 보안에 주의를 기울여야 합니다!

 

만약 애플리케이션이라면 AWS SDK 를 이용하시면 됩니다. 자바로 예를 들면 WebIdentityTokenCredentialsProvider 클래스를 이용해서 위와 같은 과정을 진행할 수 있습니다.

 

이제는 더 나아가 k8s sa token 이 유효한 토큰인지 어떻게 판단 할 수 있을까요? 결론부터 말하자면 IAM OIDC Provider 를 통해 유효한 JWT 인지 판단할 수 있습니다.

 

EKS 에서 생성된 OIDC Provider URL 은 퍼블릭으로 존재하기 때문에 어디서든 접근이 가능합니다.

따라서 아래와 같이 명령어를 주면, 

$ curl https://oidc.eks.ap-northeast-2.amazonaws.com/id/xxxx/.well-known/openid-configuration

 

json 형식의 응답을 얻을 수 있습니다. 

{
    "issuer": "https://oidc.eks.ap-northeast-2.amazonaws.com/id/xxxx",
    "jwks_uri": "https://oidc.eks.ap-northeast-2.amazonaws.com/id/xxxx/keys",
    "authorization_endpoint": "urn:kubernetes:programmatic_authorization",
    "response_types_supported": [
        "id_token"
    ],
    "subject_types_supported": [
        "public"
    ],
    "claims_supported": [
        "sub",
        "iss"
    ],
    "id_token_signing_alg_values_supported": [
        "RS256"
    ]
}

 

응답 받은 jwks_uri 로 한번 더 요청을 보냅니다.

$ curl https://oidc.eks.ap-northeast-2.amazonaws.com/id/xxxx/keys

 

그럼 JWK 을 얻을 수 있죠. 수많은 key 중 하나를 선택한 후 PEM 으로 변환해줍니다!

 

이때 key 가 여러 개 나올텐데 아무 key 를 사용하는 것이라 아니라 JWT Header 에 있는 kid(key id) 와 일치하는 key 를 사용해야 합니다.

Kid 확인

https://8gwifi.org/jwkconvertfunctions.jsp

 

받은 Public Key 를 Verify Signature 부분에 넣으면 유효한 JWT 인지를 알 수 있습니다.

 

Signature Verified

 

파드 내 애플리케이션 AWS SDK 를 이용할 때도 결국 이런 검증 과정과 발급 과정을 걸쳐 Session Token 을 받을 수 있고, 도식화 해보면 아래와 같습니다.

https://aws.amazon.com/ko/blogs/containers/diving-into-iam-roles-for-service-accounts/

 

이렇게 "ServiceAccount 에 Annotation 만 달았는데 어떻게 해당 ServiceAccount 를 마운트한 파드에서 AWS 에 접근이 가능하지?" 라는 궁금점을 해결했습니다.

 

더 나아가 어떻게 유효한 토큰인지 검증하는지도 알아보았습니다.

 

그럼 이제 토큰이 만료되었을 경우는 어떨까요? 만료된 토큰을 갱신해주어야 하는데 이걸 누가 해줄까요?

 

우선 지금까지 프로세스에서 사용된 토큰은 크게 2가지로 나눌 수 있습니다. K8S SA Token 과 AWS Session Token 입니다.

 

K8S SA Token 같은 경우는 kubelet 이 진행해줍니다. 공식 문서에 나와있죠.

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#launch-a-pod-using-service-account-token-projection

 

그럼 AWS Session Token 은 누가 갱신해 줄까요? 결론부터 말하자면 코드로 구현을 해야합니다.

AWS SDK for JAVA 같은 경우 다행히 만료되기 직전에 알아서 자동으로 갱신해준다고 합니다.

https://docs.aws.amazon.com/ko_kr/sdk-for-java/latest/developer-guide/credentials-temporary.html

 

따라서 우리는 그저 Web Identity Token(K8S SA Token) 만 잘 위치시키면 됩니다!

 

추가로 관련 코드입니다.

STSAssumeRoleWithWebIdentitySessionCredentialsProvider

ShouldDoAsyncSessionRefresh

 

이렇게 "ServiceAccount 는 JWT 형태로 토큰을 가지고 있는데 만료가 되었을 경우 어떻게 갱신하지?" 라는 궁금점도 해결했습니다.

 

평상시에 쉽게 쉽게 사용하던 IRSA 였지만, 알고보니 꽤나 복잡한 프로세스를 가지고 있었네요!

 

그럼 오늘은 여기까지~!

 

 

References

• [2024] 실무에서 사용중인 AWS 클라우드 IAM 이해와 보안
• EKS에서 쿠버네티스 포드의 IAM 권한 제어하기: Pod Identity Webhook
• Diving into IAM Roles for Service Accounts
• Introducing fine-grained IAM roles for service accounts
• IRSA 의 토큰이 만료되면 어떻게 되나요?