YG Tech Blog

이 글에서는 쿠버네티스 네트워킹의 기본 개념을 살펴보고, Service, Ingress, CNI의 핵심 개념과 역할에 대해 알아보겠습니다. 특히 MinIO와 Cilium을 활용하는 환경에서 네트워크 구성 방법을 중심으로 설명하겠습니다.📌 쿠버네티스 네트워킹 모델 이해하기✅ 쿠버네티스 네트워킹의 4가지 문제쿠버네티스는 분산 시스템으로서 네트워킹 문제를 해결하기 위한 명확한 모델을 제시합니다.▶️ 쿠버네티스가 해결하는 네트워킹 문제:컨테이너-컨테이너 통신: Pod 내 컨테이너 간 통신Pod-Pod 통신: 서로 다른 Pod 간 통신Pod-Service 통신: Pod에서 서비스로의 접근외부-Service 통신: 외부에서 클러스터 내부 서비스 접근✅ Pod 네트워킹 기본 원칙쿠버네티스의 Pod 네트워킹은 몇 가..

이 글에서는 쿠버네티스 네임스페이스의 개념과 이를 활용한 효율적인 리소스 관리 방법에 대해 알아봅니다. MinIO와 Cilium을 포함한 다양한 워크로드를 논리적으로 분리하고 관리하는 전략부터 네임스페이스 간 통신 제어까지, 구체적인 예시와 함께 살펴보겠습니다.📌 네임스페이스의 기본 개념과 필요성✅ 네임스페이스란 무엇인가?네임스페이스는 쿠버네티스 클러스터 내에서 리소스를 논리적으로 분리하는 가상 경계입니다. 동일한 물리적 클러스터를 여러 가상 클러스터로 나누어 사용할 수 있게 해주는 개념입니다.▶️ 기본 네임스페이스:# 클러스터의 기본 네임스페이스 확인kubectl get namespaces# 출력 예시:NAME STATUS AGEdefault Active ..

✅ 목표: Cilium의 L7 네트워크 정책을 활용하여,HTTP DELETE 요청을 차단하거나 특정 파드에서만 허용하는 보안 정책을 구성하고 실습합니다.🔎 이번 글에서 수행할 작업 요약MinIO 객체 삭제 요청의 위험성과 차단 필요성 이해Cilium L7 HTTP 정책을 활용한 DELETE 차단 구성허용된 파드와 차단된 파드 비교 테스트Hubble을 통해 정책 효과 시각화⚠️ 1단계: MinIO 객체 삭제 요청의 위험성이 단계의 목적: API 요청 중 DELETE 메서드가 미치는 영향과실무 환경에서 어떻게 잘못 사용될 수 있는지를 이해합니다.DELETE 요청은 버킷 또는 객체를 영구 삭제함버전 관리가 비활성화된 버킷은 복구 불가능잘못된 설정 시 누구나 curl로 DELETE 가능☑️ 이 때문에 네트워크..

✅ 목표: Cilium의 네트워크 관측 도구인 Hubble CLI와 Hubble UI를 설치하고,MinIO와 클라이언트 간의 네트워크 흐름을 실시간으로 시각화/분석하는 실습을 진행합니다.🔎 이번 글에서 수행할 작업 요약Cilium 설치 상태에서 Hubble CLI & UI 활성화Hubble UI를 LoadBalancer로 노출실제 네트워크 흐름 확인 및 필터링 테스트MinIO 접근 흐름 추적 및 분석⚙️ 1단계: Hubble 기능 활성화이 단계의 목적: 이미 설치된 Cilium에서 Hubble 기능을 활성화하고,흐름 수집과 시각화를 위한 Agent 및 Relay 구성 상태를 점검합니다.# Cilium CLI를 사용해 Hubble 기능 활성화cilium hubble enable# ✅ Hubble Agen..

✅ 목표: Cilium의 네트워크 정책에서 ServiceAccount 정보를 활용하여특정 서비스 계정에만 MinIO 접근을 허용하는 제어 방식을 실습합니다.파드의 라벨만이 아니라 역할(Role) 기반 접근 통제가 가능함을 확인합니다.🔎 이번 글에서 수행할 작업 요약테스트용 ServiceAccount 및 파드 생성Cilium 정책에서 ServiceAccount 기반 접근 허용 구성접근이 허용되는 파드와 차단되는 파드를 비교 테스트흐름 추적 및 정책 검증🧱 1단계: ServiceAccount 기반 파드 구성이 단계의 목적: 특정 ServiceAccount를 사용하는 테스트 파드를 만들고,이후 네트워크 정책에서 해당 계정을 기준으로 접근을 허용하도록 설정합니다.# etl-client-sa.yamlapiVe..

✅ 목표: Cilium의 L7(애플리케이션 레벨) 네트워크 정책을 사용해특정 파드가 MinIO에 보낼 수 있는 HTTP 요청 메서드(GET, PUT 등) 를 제한하는 방법을 실습합니다.🔎 이번 글에서 수행할 작업 요약L7 레벨에서 HTTP 메서드 제한이 필요한 상황 이해Cilium L7 HTTP 정책 구성 및 적용접근 허용/차단 결과를 테스트 파드를 통해 확인로그 기반 검증을 통해 정책 효과 확인📘 1단계: L7 HTTP 메서드 제한 필요성 이해이 단계의 목적: 단순한 IP/포트 제어가 아닌, HTTP 요청의 종류(GET, PUT, DELETE 등)를제어해야 하는 이유와 L7 정책이 필요한 상황을 이해합니다.예시 상황:분석 파드는 GET으로만 조회해야 함업로드 권한이 있는 파드는 PUT을 허용해야 함..

✅ 목표: Cilium의 L3/L4 NetworkPolicy를 사용하여 MinIO 서비스에 접근할 수 있는 Pod를 제한하고,네트워크 정책이 실제로 작동하는지 검증하는 실습을 진행합니다.🔎 이번 글에서 수행할 작업 요약MinIO에 자유롭게 접근할 수 있는 테스트 클라이언트 파드 생성Cilium L3/L4 네트워크 정책을 적용하여 접근 제어 구성접근 가능/불가능한 사례 비교 테스트네트워크 정책 동작 여부 검증🧱 1단계: 테스트 클라이언트 파드 생성이 단계의 목적: MinIO에 curl 등을 통해 접근할 수 있는 일반적인 테스트 파드를 생성하고,네트워크 정책 적용 전의 기본 동작을 확인합니다.# test-client.yamlapiVersion: v1kind: Podmetadata: name: test-..

이 글에서는 Cilium의 네트워크 정책과 쿠버네티스 기본 NetworkPolicy의 차이점을 상세히 비교해 보겠습니다. 두 정책 유형은 같은 목적을 가지고 있지만, 리소스 정의 방식, 기능 범위, 그리고 내부 동작에 있어 중요한 차이가 있습니다. 이번 글에서는 각 정책 유형의 특징, 문법적 차이, 지원하는 기능의 범위, 그리고 실제 환경에서 두 정책을 함께 사용할 때 고려해야 할 호환성 사항까지 살펴보겠습니다.📌 네트워크 정책의 기본 개념쿠버네티스에서 네트워크 정책은 Pod 간의 통신을 제어하는 규칙을 정의합니다. 이를 통해 애플리케이션의 보안을 강화하고, "최소 권한 원칙"을 구현할 수 있습니다.  ✅ 네트워크 정책의 필요성쿠버네티스는 기본적으로 모든 Pod 간 통신을 허용하는 "플랫 네트워크" 모..

이 글에서는 Cilium의 핵심 기능 중 하나인 네트워크 정책 설정에 대해 알아보겠습니다. 특히 L3(IP) 및 L4(포트) 수준에서 트래픽을 제어하는 CiliumNetworkPolicy 리소스의 기본 사용법과 실제 적용 방법을 실습을 통해 상세히 다룹니다. 전체 트래픽을 차단하는 기본 정책부터 시작하여 특정 Pod와 포트 기반의 허용 정책 작성, 그리고 정책 적용 후 상태 확인 및 로그 분석 방법까지 실무에 바로 적용할 수 있는 내용을 소개합니다.📌 네트워크 정책의 필요성쿠버네티스 환경에서는 기본적으로 모든 Pod 간 통신이 허용됩니다. 이는 개발 편의성을 제공하지만, 보안 측면에서는 큰 위험 요소가 될 수 있습니다.✅ 기본 통신 정책의 문제점쿠버네티스의 기본 네트워킹 모델은 다음과 같은 특징을 가집..

🔹 개요이번 글에서는 Istio와 Kubernetes 네트워크 정책(NetworkPolicy) 간의 충돌 문제를 해결하는 방법을 살펴보겠습니다.Istio는 서비스 메시 레이어에서 트래픽을 제어하지만, Kubernetes 자체 네트워크 정책과 충돌할 경우 예기치 않은 네트워크 차단, 접속 불가, 라우팅 오류 등의 문제가 발생할 수 있습니다.이 글에서는 Istio와 Kubernetes 네트워크 정책이 충돌하는 주요 원인, 디버깅 방법 및 해결책을 설명하겠습니다.🔹 1. Istio와 Kubernetes 네트워크 정책 충돌의 주요 원인  문제 유형  설명 Pod 간 통신 차단Kubernetes 네트워크 정책이 Istio의 트래픽 흐름을 차단Ingress 및 Egress 트래픽 제한 문제Istio Ingre..