6주차 - EKS Security - IRSA & Pod Identity(3)

6주차 - EKS Security - IRSA & Pod Identity(3)

EKS IRSA(IAM Roles for Service Accounts) 기존에는 Worker-Node 즉 EC2에 맵핑된 IAM Role를 Pod가 그대로 사용 할 수 있었다.EC2 Instance Profile : 사용하기 편하지만, 최소 권한 부여 원칙에 위배하며 보안상 권고하지 않음Pod가 탈취되면 그대로 EC2 IAM Role를 사용하여 보안적으로 취약 IRSA: Pod에 최소한의 IAM 권한을 주는것          파드가 특정 IAM 역할로 Assume 할때 토큰을 AWS에 전송하고, AWS는 토큰과 EKS IdP를 통해 해당 IAM 역할을            사용할 수 있는지 검증  실습  1 ( service account Token - false) 1. Pod 생성 시 Service A..

  • format_list_bulleted 2025_AEWS Study
  • · 2025. 3. 16.
  • textsms
6주차 - EKS Security - EKS 인증/인가(2)

6주차 - EKS Security - EKS 인증/인가(2)

EKS 인증/인가 AWS EKS의 경우 사용자 인증은 AWS IAM / 인가는 K8S의 RBAC을 사용EKS 인증 모드: API / ConfigMapConfigMap의 경우 Deprecation 예정   EKS 사용자 인증 /인가 IAM 인증을 위한 Token 요청(eks get token)발급받은 Token을 통하여 Pre-Signed URL을 Bearer Token으로 EKS API Cluster Endpoint로 요청 EKS API는 Token Review 를 Webhook token authenticator에 요청 ⇒ (STS GetCallerIdentity 호출) AWS IAM 해당 호출 인증 완료 후 User/Role에 대한 ARN 반환 ConfigMap에서 반환된 Role ARN과 맵핑 정보..

  • format_list_bulleted 2025_AEWS Study
  • · 2025. 3. 16.
  • textsms
6주차 - EKS Security - 인증/인가(1)

6주차 - EKS Security - 인증/인가(1)

K8S 인증/인가 Kubernetes에서는 API 통신을 위하여 인증(Authentication), 인가/권한(Authorization), Admission Control(승인제어) 단계를 거치게 된다. 인증(Authentication): Kubernetes를 사용하는 사용자가 검증된 사용자인지를 확인하는 절차 X.509 Client Certs : kubeconfig 에 CA crt(발급 기관 인증서) , Client crt(클라이언트 인증서) , Client key(클라이언트 개인키) 를 통해 인증kubectl : 여러 클러스터(kubeconfig)를 관리 가능 - contexts 에 클러스터와 유저 및 인증서/키 참고Service Account : 기본 서비스 어카운트(default) - 시크릿(CA..

  • format_list_bulleted 2025_AEWS Study
  • · 2025. 3. 15.
  • textsms
5주차 - EKS Autoscaling(Karpenter)

5주차 - EKS Autoscaling(Karpenter)

Karpenter 고성능의 지능형 k8s 컴퓨팅 프로비저닝 및 관리 솔루션, 수초 이내에 대응 가능, 더 낮은 컴퓨팅 비용으로 노드 선택지능형의 동적인 인스턴스 유형 선택 - Spot, AWS Graviton 등자동 워크로드 Consolidation 기능일관성 있는 더 빠른 노드 구동시간을 통해 시간/비용 낭비 최소화동작  Consolidation Consolidation 동작 방식중단 비용 - 예) 파드가 많이 배치되어서 재스케줄링 영향이 큰 경우 등 , 오래 기동된 노드 TTL, 비용 관련관리 간소화  CA의 경우 AWS ASG와 CA 모두 동작을 해야 하기 때문에 시간이 오래 걸림ASG의 경우 주체가 AWS이고, CA의 경우 EKS가 주체이기 때문에 각 각 확인을 해야 함 Karpenter의 경우 ..

  • format_list_bulleted 2025_AEWS Study
  • · 2025. 3. 7.
  • textsms
5주차 - EKS Autoscaling(CAS→Node Autoscaling)

5주차 - EKS Autoscaling(CAS→Node Autoscaling)

Node Autoscaling Node Autoscaling이란 Kubernetes 클러스터에 과도한 부하 및 이벤트가 발생하여 Pod가 Node에 할당되지 못하여 Pending상태가 되는 경우 추가 Node를 생성하여 해당 Node에 Pod를 배치하는 것을 의미한다.즉 Node의 Scale In/Out, Scale Up/Down을 의미   CAS: Cluster AutoscalerEKS의 경우 AWS Auto Scaling Group를 사용하여 Cluster Autoscaler에 적용 설치 및 확인# EKS 노드에 이미 아래 tag가 들어가 있음# k8s.io/cluster-autoscaler/enabled : true# k8s.io/cluster-autoscaler/myeks : ownedaws ec..

  • format_list_bulleted 2025_AEWS Study
  • · 2025. 3. 7.
  • textsms
5주차 - EKS Autoscaling(HPA/KEDA/VPA → Pod Autoscaling )

5주차 - EKS Autoscaling(HPA/KEDA/VPA → Pod Autoscaling )

Autoscaling이란오토스케일링(autoscaling)은 서버 팜의 컴퓨팅 리소스 양(일반적으로 활성 서버 수로 측정)을 동적으로 조정하는 클라우드 컴퓨팅에 사용되는 한 방식이다. (위키백과) 클라우드를 배우면서 클라우드의 장점이라고 배우는 내용 중 "Autoscaling"은 빠질 수 가 없다.웹 서비스를 운영한다고 했을 경우, 트래픽이 증가하게 되면 이에 적절하게 서버의 스펙 증가 (Scale-UP/Down)을 하거나, 서버의 수를 증가(Scale-In/Out)하여 대처를 하게 된다. Kubernetes 환경에서도 동일하게 트래픽이 증가한다면 어떻게 해결해야 할까?수평 확장 Horizontal Scaling운영 환경에 더 많은 워크로드(VM, Task, Pod)를 추가하는 방식트래픽을 여러 워크로드..

  • format_list_bulleted 2025_AEWS Study
  • · 2025. 3. 7.
  • textsms