[패스트캠퍼스 챌린지 20일차] '76가지 DevOps 모의 실무 예제: AWS 기반 인프라 구축부터 재해복구, 보안까지' 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
※ 챌린지 URL: https://abit.ly/lisbva

 

수강시작 인증사진

 

  EKS 클러스터를 생성한 후, 실질적으로 클러스터에 접근하고 관리하기 위해 필요한 절차들을 하나씩 살펴보았다. 이번 강의에서는 단순히 클러스터를 만든다고 끝나는 것이 아니라, kubeconfig 등록부터 시작해서 IAM 기반 인증, 그리고 Kubernetes RBAC 기반 인가 설정까지 전반적인 접근 제어 흐름을 이해할 수 있었다.

 

  우선 aws eks update-kubeconfig 명령어를 통해 EKS 클러스터에 접근하기 위한 kubeconfig 설정을 로컬에 반영했다. 이 과정은 비교적 간단했지만, 단순한 명령어 한 줄로 AWS IAM과 Kubernetes 환경이 맞물려 동작한다는 점이 꽤 흥미로웠다. 해당 설정을 통해 kubectl을 사용할 수 있게 되며, 이후 context를 전환하여 실제 클러스터에 명령을 내릴 수 있게 된다.

 

  클러스터 접근의 핵심은 인증(Authentication)과 인가(Authorization)로 나뉜다. 인증은 누가 접근하는지를 확인하는 과정으로, AWS에서는 IAM을 통해 이 과정을 처리한다. kubectl 명령을 실행할 때마다 AWS IAM 자격 증명을 사용해 인증 토큰을 생성하고 이를 기반으로 클러스터 접근을 시도하게 된다. 여기까지는 AWS의 영역이다.

 

  하지만, Kubernetes 내에서 리소스에 접근할 수 있는지 여부는 Kubernetes 고유의 RBAC 시스템을 통해 결정된다. 즉, AWS IAM에서 인증을 받았다고 하더라도, 해당 사용자나 역할이 클러스터 내에서 적절한 권한을 갖고 있지 않다면 실제 리소스에 접근할 수는 없다. 이런 이유로 IAM 엔터티와 Kubernetes Role/Group 간의 연결이 필수적이다.

 

  이 연결고리를 설정하는 방법 중 하나가 aws-auth ConfigMap을 수정하는 것이다. 실습에서는 Terraform 설정을 통해 manage_aws_auth_configmap = true로 지정하고, IAM Role과 User를 system:masters 그룹에 포함시키는 방식으로 접근 권한을 부여했다. system:masters는 클러스터 내에서 거의 모든 작업을 수행할 수 있는 권한을 가진 그룹이기 때문에, 실제 운영에서는 조금 더 세분화된 권한 설계가 필요하겠지만, 학습 목적에서는 이해를 돕는 데 충분했다.

 

  이러한 과정을 통해 IAM Role이나 User가 클러스터에 접근하고, 실제로 리소스를 생성·조회·수정할 수 있는 권한까지 부여받게 된다. 즉, AWS 계정과 Kubernetes 클러스터 간의 권한 흐름을 매핑해주는 과정이 잘 정리되어 있어야만, 여러 명이 함께 클러스터를 안전하게 사용할 수 있는 기반이 마련된다.

 

  실습을 통해 느낀 점은, EKS가 AWS의 IAM 체계를 기반으로 Kubernetes의 인증 과정을 처리함으로써 보안과 통합 관리를 상당히 잘 녹여냈다는 것이었다. 다만, 그만큼 처음 접하는 사람 입장에서는 IAM과 RBAC을 동시에 이해하고 다뤄야 한다는 부담도 존재한다. 이를 어떻게 자동화하거나 체계적으로 관리할지는, 이후 팀 단위 운영 시 고민해야 할 과제가 될 듯하다.

 

  이번 학습에서는 단순한 접근 권한 설정을 넘어서, AWS와 Kubernetes 사이의 인증·인가 메커니즘을 실습을 통해 체감할 수 있었고, 실무에 투입될 때 어떤 부분을 명확히 이해하고 있어야 할지에 대한 기준이 조금씩 생기고 있는 듯하다. 다음 단계에서는 이 권한 설정이 실제 워크로드나 네임스페이스 단위로 어떻게 적용되는지, 그리고 서비스 계정과의 연동 방식도 함께 살펴보면 좋을 것 같다.

 

수강종료 인증사진

수강종료 후 강의목차

수강종료 후 학습통계