AEWS 6주차. EKS Security

모든 보안의 기본은 올바른 인증과 권한(인가)을 어떻게 제어하느냐로부터 시작합니다.

K8s도 예외는 아니며, 특히 EKS에서는 다양한 native AWS 서비스를 활용하여 인증과 인가를 처리합니다.

  - 인증(Authentication) : 접근한 사용자 또는 서비스가 정상적인 사용자인지를 확인

  - 인가(Authorization) : 해당 사용자가 어떠한 권한을 가지고 있는지, 어떤 역할을 담당하는지 정의

 

EKS는 인증/인가와 관련하여 AWS IAM 서비스에 대한 의존도가 높습니다.

AWS IAM에서 제공하는 자격증명과 정책 설정 등을 통해 EKS 자체의 운영환경뿐만 아니라

EKS와 연계되어 운영될 수 있는 다양한 AWS 서비스에 대한 권한관리를 수행합니다.

 

결과적으로 EKS에서는 기본적인 k8s의 인증 대신에

AWS IAM을 처리하여 사용자 인증체계를 IAM으로 통합하고 있으며,

인가는 K8s RBAC을 그대로 사용하고 있습니다.

 

기본적인 k8s에서의 API 서버 인증/인가 처리 단계를 보면, 

API 서버에 하나 이상의 인증 플러그인을 구성할 수 있습니다.

이 플러그인 중에서 하나에서 인증 요청을 호출하면

나머지 플러그인의 호출을 뛰어넘어서 인가 단계로 진행하게 됩니다.

인가단계에서는 RBAC 플러그인 등을 거치면서 해당 요청이 특정 리소스에 대해서 허용되었는지 검사하고,

Admission Control을 통해서 분산저장소인 etcd에 최종적으로 저장하게 됩니다.

 

이와 관련된 정보는 k8s의 .kube/config 파일에 정의되어 있습니다.

  - clusters : kubectl 이 사용할 쿠버네티스 API 서버의 접속 정보 목록

  - users : 쿠버네티스의 API 서버에 접속하기 위한 사용자 인증 정보 목록

  - contexts : cluster 항목과 users 항목에 정의된 값을 조합해 최종적으로 사용할 클러스터의 정보를 설정

 

K8s의 권한인가체계인 RBAC에서는 권한을 갖는 사용자와 Service Account, 그리고 권한을 명시한 Role,

마지막으로 Role과 사용자나 Service Account를 연결하는 Role Binding의 구조를 갖습니다.

그리고 권한할당을 위한 Role은 Namespace에 제한되느냐,

아니면 클러스터 전체에 적용되느냐에 따라 일반 Role과 Cluster Role로 나뉘게 됩니다.

 

즉, 보안 주체인 사람을 나타내는 user나 group과 애플리케이션이 사용하는 보안 주체인 Service Account를

특정리소스에 대해서 어떤 액션을 수행할 수 있는지를 정의한 Role이나 Cluster-role과 

Role Binding이나 Cluster Role Binding으로 연계해서 권한 인가 체계를 구성하게 됩니다.

 

이러한 권한 할당을 위한 구조는 EKS에서도 동일하게 적용이 되는데,

EKS 환경의 특징이라면 EKS에서의 인증은 AWS IAM을 통해서 이루어진다는 점입니다.

예를 들어, Service Account에서 AWS API에 대한 접근이 필요한 경우가 있는 경우,

Service Account에 IAM Role을 맵핑하여 권한을 부여할 수 있습니다.

 

EKS 클러스터에 접근할 수 있는 사용자 PC에서 kubectl을 실행시

IAM을 활용해 사용자를 인증하고, k8s에 정의된 권한에 따라 해당 명령을 인가하게 됩니다.

 

1. kubeconfig 설정정보에 정의된 EKS Get-Token 명령어를 통해 EKS service endpoint(STS)로 토큰 발행을 요청

  - STS Security Token Service

    : AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명(STS)을 생성하여 신뢰받는 사용자에게 제공

2. response로 토큰 값이 전달

  - Base64로 인코딩 -> 디코딩시 Secure Token Service의 GetCallerIdentity를 호출하는 pre-signed URL을 확인

3. kubectl의 client-go 라이브러리는 Pre-signed URL을 Bearer Token으로 EKS API Cluster Endpoint로 요청을 보냄

4. IAM Authentication server는 Token Authentication Webhook을 호출하고 이는 STS GetCallerIdentity를 호출

5. AWS IAM에서는 해당 호출에 대한 인증과정을 거쳐 UserID와 User나 Role에 대한 ARN을 반환

6. 반환된 정보를 AWS-auth에게 전달하고, AWS-auth는 K8s의 보안 주체를 리턴

  - AWS-auth : IAM의 User나 Role을 K8s의 User나 Group으로 매핑하는 Config Map

7. Authentication에서는 Token Review라는 데이터 타입으로 username과 group을 반환

8. 반환된 값을 이용해 k8s RBAC 체계에서 요청에 대한 허용이나 거부를 처리

 

K8s는 내부적으로 다양한 구성요소를 포함하고 있지만, API 사용을 위한 인증 구조는 포함하고 있지 않습니다.

즉, 자체적으로 인증을 수행하지 않는 대신 외부의 인증 수단을 통해 인증 정보를 수신하고 

K8s에서는 권한에 대한 인가만을 수행합니다.

 

이를 위해 EKS에서는 IAM을 통해 인증을 수행합니다.

EKS에서는 IAM Authenticator을 통해서 EKS내의 인증을 IAM과 연계시키게 되기 때문에,

EKS 사용을 위해선 사용자 단말에 kubectl과 함께 IAM Authenticator도 설치가 되어 있어야 합니다.

 

① K8s 운영을 위해 사용자가 kubectl 명령을 실행하게 되면,

② 내부적으로 IAM Authenticator의 Client Module이 

단말에 설정된 IAM 사용자의 자격증명 정보를 기반으로 Token을 발급하게 되며,

③ 결과적으로 사용자의 kubectl 명령은 이 Token과 함께 API 서버로 전달되게 됩니다.

④ API 서버는 사용자로부터 전달받은 내용 중 Token에 대한 검증을 위해 

API 서버 내부에 설치된 IAM Authenticator Server에게 토큰을 전달하게 되고

⑤ 토큰을 전달받은 IAM Authenticator Server는

Token의 유효성 검증을 위하여 해당 토큰을 AWS STS로 다시 전달하게 됩니다.

STS에서는 Authenticator Server로부터 수신한 호출의 유효성을 검증하게 되고

⑥ 만일 정상적인 IAM 자격증명이라면 Authnticator에게 성공 메시지를 전달하게 됩니다.

⑦ STS로부터 성공 메시지를 수신한 Authenticator Server는 AWS Auth Config Map을 통해 

해당 자격증명에 맵핑되어 있는 K8s 사용자 정보를 확인한 후에 API 서버에 인증의 성공을 전달하게 됩니다.

⑧ 결과적으로 최초 사용자의 API 호출에 대해 "인증 성공 응답"을 전달받은 API 서버는 인가를 위해 

해당 사용자에 대한 권한을 확인하는 작업을 수행하게 됩니다.

⑨ 사용자에 Binding되어 있는 권한이 사용자가 실행한 Action을 포함하고 있다면 요청은 허용되게 됩니다.

 

즉 EKS 환경에서는 IAM Authenticator Client와 Server가

각각 사용자와 API 서버에서 동작하면서 IAM에 기반한 인증을 수행합니다.

 

사용자가 아닌 Service Account를 위한 IAM 기능에 대해 살펴보도록 하겠습니다.

 

K8s를 AWS 환경에서 사용하다보면 각 pod에서 AWS 서비스에 대한 접근 권한이 필요한 경우가 생길 수 있습니다.

이 경우 가능한 권한 부여 방식은 각 pod에 사용가능한 Service Account를 이용하여 권한을 부여하거나 

EC2에 할당된 인스턴스 프로파일을 활용하는 것입니다.

 

EC2 Instance Profile을 사용하면 간단한 코드를 통해 Role의 권한을 사용할 수 있는 장점이 있지만,

하나의 Node에서 구동되는 여러 Pod들이 동일한 권한을 가져간다는 점에서 권장되는 방식은 아닙니다.

 

이를 위해 EKS에서는 IAM Role for Service Account(IRSA)라는 기능을 제공하며, 

이 기능은 각 pod에서 사용하는 Service Account별로 별도의 IAM Role을 사용하는 것을 목적으로 하고 있습니다.

 

 

IRSA를 이용하여 각 Service Account별로 IAM Role을 맵핑하기 위해서는 몇가지 준비 작업이 필요합니다.

  1. 먼저 OIDC 기반의 IdP를 IAM에 등록해야 합니다.

  2. 그리고 Service Account에 맵필할 IAM Role을 생성하고

  3. Policy를 할당해줘야 합니다.

  4. 이 IAM role이 준비가 되었다면 Role을 사용할 Service Account를 생성해야 합니다.

  5. 그리고 마지막으로 Service Account에 대한 Annotation을 추가하면

각 pod에서 사용되는 Service Account에 대한 IAM Role의 맵핑이 완료되게 됩니다.

 

이렇게 IRSA를 사용면 여러가지 목적을 가지는 서로 다른 Pod에 대해서

제한된 권한을 갖는 서로 다른 Role을 맵핑하는 것이 가능해집니다.

 

예를 들어 S3에 접근이 필요한 pod는 Service Account를 통해 S3에 접근권한을 갖는 Role을 사용하게 되고 

KMS에 접근이 필요한 pod는 Service Account를 통해 KMS에 대한 접근권한을 갖는 Role을 사용하게 됩니다.

 

 

관련 실습

-----------------------------------------------------------------------------------------------

이 내용은 AEWS(AWS EKS Workshop Study) 1기의 과제로써 작성되었습니다.

AEWS는 '가시다'님이 속한 CloudNet@에서 진행하는 AWS EKS workshop에 대한 스터디입니다.

매주 일요일마다 소중한 정보를 퍼주시는 '가시다'님께 무한 감사 드립니다.

https://gasidaseo.notion.site/23-AWS-EKS-Workshop-07165aec800042b9ac9357aee18fdf17