전체 글

시나리오 개요Starting with a very limited set of permissions, the attacker is able to leverage the instance-profile-attachment permissions to create a new EC2 instance with significantly greater privileges than their own. With access to this new EC2 instance, the attacker gains full administrative powers within the target account and is able to accomplish the scenario's goal - deleting the cg-super-cr..

ABACAttribute-Based Access Control, User나 Group에 Permission Attribute를 지정해 접근을 제어하는 방식이 방법은 개별 User나 Group에 대해 각각 권한 설정을 해줌에 따라 복잡하고 세밀한 권한제어가 가능하다. 허나 User나 Group의 수가 증가하게되는 경우, 이들을 일일히 ABAC로 권한 설정을 해주기는 어려울 것이다.   ABAC policy 파일의 구성은 다음과 같다. 아래 Policy는 user 'jane'이 default namespace의 pod를 읽을 수 있도록 하는 내용이다. # abac_policy.json{ "apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": ..

kube 커맨드를 실행하기 위해 Kube API Server에 명령어를 Query해주어야한다.API Server에 Query하기 위해서는 User 인증을 위해 매번 User Certificate를 함께 보내주어야한다. kubectl get pods --server kubernetes.docker.internal:6443 \ --client-key admin.key \ --client-certificate admin.crt \ --certificate-authority ca.crt 매번 이렇게 커맨드를 실행할 수는 없지 않은가? 이 과정을 간소화시키기 위해 Context와 KubeConfig 파일이 존재한다. KubeConfig클러스터에 접근하고 상호작용하기 위해 필요한 설정을 포함하는 파일kubectl을..

Terraform을 통해 aws_instance를 만들면 기본 AMI값을 지정해주어야한다. 이 ami 값은 외우기도 좀 그렇고 자주 바뀌는 터라, 동적으로 가져와서 지정해줄 필요가 있다. Terraform의 'data' Block을 사용해 특정한 AMI 값을 AMI Marketplace에서 검색해 가져올 수 있다.예시로 ubuntu-22.04의 AMI 값을 가져와 본다.data "aws_ami" "ubuntu" { most_recent = true owners = ["099720109477"] # Canonical(Ubuntu 배포사)의 AWS 계정 ID filter { name = "name" values = ["ubuntu/images/hvm-ssd/ubuntu-jammy..

시나리오 목표"vault" 컨테이너에 Access해 플래그 획득  시나리오 세팅./cloudgoat.py create ecs_takeover  EC2 인스턴스의 Public IP가 연결된 DNS 주소 하나가 주어진다.  ECS 클러스터 구조문제에 돌입하기 전에 ECS 서비스에 대한 구조를 간략하게 알고 넘어가보자.ECS의 리소스는 cluster, service, task, container로 구성되어있다. 이러한 구조는 k8s와도 살짝 닮아있는 것을 알 수 있다. Component설명ClusterECS Service와 Task를 실행하는 인프라, service와 task를 묶는 논리적인 단위가 된다. ECS의 가장 상위 수준의 리소스ServiceTask의 지속적인 실행을 관리하는 개체로, Task를 실행..

Cluster내에서는 여러 Worker Node들이 연결되어 있고,  각 Node에는 여러 Pod들이 배치될 수 있다.배치된 Pod들은 CPU를 많이 잡아먹는 Workload, 혹은 메모리를 많이 잡아먹는 Workload 등 다양한 요구사항을 가질 수 있다. 그리고 Worker Node 또한 각각 사양이 다를 수 있기에, 이러한 요구사항과 cluster 내의 Node 상황에 맞춰 Pod를 효율적으로 Scheduling 하는 것이 중요하다. 효율적인 Pod의 Scheduling을 위해 Kubernetes에서는 Resource Requests와 Limits를 사용한다.이번에는 이 두 요소를 알아보도록 한다. Resource RequestsContainer가 생성될 때, 특정 용량을 요청하는 것, 해당 pod..

Taint & Tolerant어떤 pod가 특정 node에 schedule되는 것을 제한하는 것 (set restriction)즉, 특정 node가 특정 pod만 수용할 수 있도록 하거나 특정 node에 특정 pod가 배치되지 않도록 하는 수단이다. Taint는 node에 지정하는 요소이고, Tolerant는 pod에 지정하는 요소다.이해하기 쉽게 보자면, Taint는 '벌레 퇴치 스프레이', 그리고 Tolerant는 Taint에 적응할 수 있는 면역력으로 생각할 수 있다.  Taint와 Tolerant를 이해하기 위해 아래와 같이 Node와 Pod들이 있다고 가정해본다.  Node라는 사람 객체에 Pod라는 벌레 객체가 붙는다. 이때 Node에 예를 들어 app=prd 라는 Taint를 적용하게되면, ..

Pod를 새롭게 생성하면 Master Node(Control plane)의 Scheduler가 pod를 실행시킬 node를 선택하고 배치한다.그럼 이 Scheduler는 어떤 기준으로 pod를 실행시킬 node를 결정하는 것일까?cluster내의 node들은 모두 같은 사양을 가질수도 있지만, 각기 다른 스펙의 사양을 가질 수도 있다. 워크로드 또한 리소스 자원을 많이 요구하는 것이 있고, 비교적 적은 양을 요구하는 것이 있다. 각 node들의 리소스를 효율적으로 사용하기 위해서는 다양한 제약 조건과 요구사항 등을 고려하여 pod를 배치해야한다. 특정 워크로드가 적합한 노드에서 실행되도록 할 수 있다.이번 글에서는 Label과 Selector, 추가로 Annotation에 대해 알아보도록 한다. Labe..