Ncloud API를 활용한 자동화 작업 #0

# 🤔Ncloud API 사용 이유 반복적으로 Ncloud에서 운영중인 서버의 특정 시간 대 리소스 사용량을 조회해서 엑셀로 정리 및 메일로 송부해야하는 작업이 생겼다. 귀찮고 너무 귀찮고 번거로워서 이러한 작업을 API를 활용해 자동화로 구성해보고 싶었다. # 😠난 코딩을 해본적이 없다 간단한 코딩은 C언어로 for문 사용해서 별찍기 정도만 할 줄 아는 정도이다. API를 사용해본적도 없고 더구나 Python이란 언어도 사용해본적이 없다. 어떻게 작업을 해야 할지 몰라 일단 무작정 구글링을 시작으로 작업을 시작했다. # 😠Ncloud API 관련 정보가 너무 없어서 고생했다. Ncloud 관련 API를 사용하는 블로그 및 정보를 찾지 못해서 고생을 많이 했다. 또한 Ncloud에서 제공하는 API..

• format_list_bulleted 네이버클라우드
• · 2024. 4. 16.
• textsms

6주차 - EKS Security - Kyverno & 보안 위협 시나리오

이번 포스팅 내용은 Policy Engine인 Kyverno 및 K8S에서 보안 위협이 될 수 있는 몇 가지 시나리오를 실습할 예정이다. EKS pod가 IMDS API를 악용하는 시나리오 1. 취약 Web Server Pod 생성 cat

• format_list_bulleted AEWS Study
• · 2024. 4. 14.
• textsms

6주차 - EKS Security - IRSA & Pod Identity

EKS IRSA(IAM Roles for Service Accounts) 기존에는 Worker-Node 즉 EC2에 맵핑된 IAM Role를 Pod가 그대로 사용 할 수 있었다. 따라서 Pod가 탈취되면 그대로 EC2 IAM Role를 사용하여 보안적으로 취약할 수 있다. 이에 노드가 아닌 Pod에 최소한의 IAM 권한을 주는것이 IRSA이다. 실습 1 ( service account Token - false) 1. Pod 생성 시 Service Account Token이 자동 마운트 설정 해제 # 파드1 생성 cat

• format_list_bulleted AEWS Study
• · 2024. 4. 13.
• textsms

6주차 - EKS Security - 사용자 인증/인가

K8S 인증/인가 Kubernetes에서는 API 통신을 위하여 인증(Authentication), 인가/권한(Authorization), Admission Control(승인제어) 단계를 거치게 된다. 인증(Authentication): Kubernetes를 사용하는 사용자가 검증된 사용자인지를 확인하는 절차 - User Account: Kubernetes를 사용하는 사용자 계정 ex) AWS 로그인 계정 - Service Account: Pod에서 실행되는 프로세스에 대한 식별자를 제공 / Namespace로 구분 ex) AWS IAM 인가/권한(Authorization): 사용자 행위에 대해서 권한이 있는지를 확인하는 절차 / RBAC기반으로 동작 - User Account 별 Role/Rolebi..

• format_list_bulleted AEWS Study
• · 2024. 4. 9.
• textsms

5주차 - EKS Autoscaling - Karpenter

Karpenter CA의 경우 AWS ASG와 CA 모두 동작을 해야 하기 때문에 시간이 오래 걸림 ASG의 경우 주체가 AWS이고, CA의 경우 EKS가 주체이기 때문에 각 각 확인을 해야 함 Karpenter의 경우 ASG를 사용하지 않고 Karpenter 자체적으로 동작하기 때문에 CA보다 훨씬 빠르게 동작 Karpenter 설치 기존 배포한 EKS 삭제 후 새로운 EKS 배포 # 변수 정보 확인 export | egrep 'ACCOUNT|AWS_' | egrep -v 'SECRET|KEY' # 변수 설정 export KARPENTER_NAMESPACE="kube-system" export K8S_VERSION="1.29" export KARPENTER_VERSION="0.35.2" export T..

• format_list_bulleted AEWS Study
• · 2024. 4. 7.
• textsms

5주차 - EKS Autoscaling - (Node Autoscaling)

두번 째 포스트 주제는 Node Autoscaling이다. Node Autoscaling이란 Kubernetes 클러스터에 과도한 부하 및 이벤트가 발생하여 Pod가 Node에 할당되지 못하여 Pending상태가 되는 경우 추가 Node를 생성하여 해당 Node에 Pod를 배치하는 것을 의미한다.즉 Node의 Scale In/Out, Scale Up/Down을 의미   CA: Cluster Autoscaler EKS의 경우 AWS Auto Scaling Group를 사용하여 Cluster Autoscaler에 적용 EKS 배포 시 Tag 설정EC2 Autoscaling 내 ASG 생성 확인awscli명령어를 통해 클러스터 노드의 수량 조절 / MaxSize 6개로 변경aws autoscaling desc..

• format_list_bulleted AEWS Study
• · 2024. 4. 5.
• textsms

5주차 - EKS Autoscaling - (Pod Autoscaling)

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

• format_list_bulleted AEWS Study
• · 2024. 4. 5.
• textsms