오늘날의 분산 시스템에서 정책 과부하를 탐색하기 위한 가이드

KubeCon에 참석하여 "정책"에 관한 세션에 참석하시기 바랍니다. "이게 도대체 어떤 정책인가요?"라는 의문이 들더라도 놀라지 마세요.

최근 솔트레이크시티에서 열린 큐브콘에서 저는 '정책'이 제목에 눈에 띄는 세션 사이를 전력 질주하는 저를 발견했습니다. 그러나 각 화자에게 이 단어는 완전히 다른 의미를 가졌습니다.

라벨 기반 네트워크 정책에 집중하는 사람으로서 저는 종종 연사에게 "이 정책 세션이 네트워크 정책에 관한 건가요, 승인 컨트롤러에 관한 건가요, 아니면 규정 준수에 관한 건가요?"라고 미리 물어봐야 했습니다.

이러한 교환은 오늘날의 클라우드 네이티브 및 분산 컴퓨팅 생태계에서 점점 더 커지고 있는 문제를 보여줍니다. '정책'이라는 용어는 너무 광범위하게 사용되어 사실상 그 자체가 추상화되어 있습니다.

이 문제를 풀기 위해 이 광범위한 용어에서 자주 논의되는 8가지 유형의 정책과 분산 시스템의 인프라, 보안 및 자동화를 이해하는 데 왜 중요한지 자세히 살펴보겠습니다.

1. 네트워크 정책

네트워크 정책은 네트워크의 시스템들이 서로 통신하는 방식을 제어하고 관리하는 데 중요하며, 특히 Kubernetes와 같은 환경에서는 더욱 그렇습니다.

대부분의 네트워크 정책은 허용 목록 방식을 사용합니다. 즉, 정책에서 특별히 허용하지 않는 한 기본적으로 연결이 차단됩니다. 이러한 정책은 IP 주소 또는 레이블을 기반으로 하는 규칙을 사용하여 어떤 리소스가 통신할 수 있는지 결정할 수 있습니다.

마이크로서비스와 컨테이너 기반 애플리케이션이 보편화됨에 따라 서비스 통신 방식을 신중하게 제어하고 필요할 때 격리하는 것이 더욱 중요해졌습니다.

예를 들어, 쿠버네티스 네트워크 정책은 고도로 사용자 정의할 수 있습니다. 내부 트래픽(동서 방향)과 외부 트래픽(남북 방향)에 대한 트래픽 규칙을 설정할 수 있습니다. 이러한 유연성으로 인해 시스템을 안전하게 유지하는 강력한 도구가 되기도 하지만, 구축 및 관리가 더 복잡해지기도 합니다.

2. 입장 관리자 정책

어드미션 컨트롤러는 쿠버네티스의 전문화된 정책입니다. API 요청을 평가하여 허용 또는 변경 여부를 결정합니다. 이들은 본질적으로 게이트키퍼입니다. API 요청이 진행되기 전에 클러스터 전체에 특정 표준 또는 보안 관행을 적용합니다.

예를 들어, 입장 관리자 정책은 다음과 같습니다:

• 리소스 제한 자동 적용

• 배포에 레이블 추가

• 안전하지 않은 구성이 사용되지 않도록 차단

이러한 종류의 정책은 요청을 가로채고 변경할 수 있습니다. 따라서 클러스터 내에서 일관된 보안을 유지하는 데 매우 중요합니다. 그러나 이들은 Kubernetes API 호출 라이프사이클의 정책만 다룹니다.  

3. OPA 및 Kyverno 정책

OPA 및 Kyverno 정책은 단순히 입장 제어기인가요, 아니면 그 이상의 무엇인가요?

OPA(오픈 정책 에이전트)와 Kyverno는 기존 입장 컨트롤러보다 더 많은 기능을 제공합니다. 이들은 종종 Kubernetes에서 어드미션 컨트롤러로 작동하지만, 보다 유연하고 포괄적인 정책 언어를 도입합니다. 이를 통해 조직은 여러 시스템에서 복잡한 규칙을 정의하고 적용할 수 있습니다.

• OPA(오픈 정책 에이전트 )는 여러 환경에서 사용할 수 있는 다목적 정책 엔진입니다. 복잡한 정책 요구 사항을 처리할 수 있는 Rego라는 언어를 사용합니다. Kubernetes 외에도 OPA는 CI/CD 파이프라인, 마이크로서비스, 심지어 클라우드 리소스에 대한 정책을 관리할 수 있습니다.

• Kyverno는 쿠버네티스를 위해 특별히 제작된 정책 엔진입니다. YAML에서 정책을 정의하는 더 간단한 방법입니다. 많은 사람들이 쿠버네티스를 구성할 때 이 방법을 선호합니다. 기본 Kubernetes 개체와 잘 작동하므로 정책을 쉽게 빌드하고 적용할 수 있습니다.

이러한 도구는 시스템에 액세스할 수 있는 항목을 제어할 수 있지만, 다양한 앱과 시스템에서 훨씬 더 많은 작업을 수행할 수 있습니다. 관리할 수 있습니다:

• 라이프사이클 관리

• 유효성 검사

• 사용자 지정 규정 준수 확인

4. 리소스 할당량 및 제한 정책

리소스 관리 정책은 쿠버네티스 클러스터가 사용할 수 있는 CPU, 메모리 및 스토리지의 양을 제어하는 데 도움이 됩니다. 이러한 정책은 한 앱이나 사용자가 너무 많은 리소스를 사용하는 것을 방지하기 때문에 공유 환경에서 중요합니다.

• 할당량은 일반적으로 각 네임스페이스에 대해 설정됩니다. 네임스페이스가 사용할 수 있는 리소스의 총량을 제한하여 하나의 네임스페이스가 너무 많은 리소스를 차지하지 않도록 합니다.

• 제한은 컨테이너 또는 파드가 사용할 수 있는 최소 및 최대 리소스 수를 정의합니다. 이렇게 하면 단일 워크로드가 너무 많은 리소스를 사용하여 나머지 시스템에 문제를 일으키지 않도록 할 수 있습니다.

이러한 정책을 통해 관리자는 리소스의 균형을 맞출 수 있으며, 이는 사용자가 많은 환경이나 동적으로 확장하는 앱에서 특히 중요합니다. 이러한 정책은 시스템을 안정적으로 유지하는 데 도움이 되지만 자동화 및 허용 제어와 같은 다른 정책 계층과 상호 작용하기 때문에 상황을 더 복잡하게 만들기도 합니다.

이러한 정책은 관리자가 리소스 균형을 맞추는 데 도움이 되며, 이는 사용자가 많은 시스템이나 동적으로 확장하는 앱에서 특히 중요합니다. 그러나 이러한 정책을 관리하는 것은 어려울 수 있습니다. 이러한 정책은 자동화 및 입학 관리와 같은 다른 정책과 중복되는 경우가 많습니다.

5. 파드 보안 정책(PSP)

쿠버네티스의 파드 보안 정책(PSP)은 파드 수준에서 보안 구성을 설정한다. 여기에는 컨테이너가 루트로 실행되는 것을 중지하거나 특정 Linux 기능을 요구하는 것이 포함됩니다.  

하지만 Kubernetes에서는 PSP가 단계적으로 폐지되고 있습니다. 이들은 파드 보안 표준(PSS)과 같은 최신 옵션과 OPA 및 Kyverno와 같은 외부 도구로 대체되고 있습니다.

PSP는 지나치게 허용적인 구성으로 워크로드가 실행되는 것을 방지하는 세분화된 보안 설정을 추가하도록 설계되었습니다. 유용하지만 다른 정책과 함께 PSP를 관리하면 혼란스러울 수 있습니다. 최신 도구는 "보안 정책이라는 일반적인 용어로 보안을 보다 유연하게 적용할 수 있는 방법을 제공합니다."

6. 서비스 메시 정책

마이크로서비스 환경에서는 Istio 또는 Linkerd와 같은 서비스 메시가 서비스 간의 통신을 보호하고 모니터링하는 또 다른 정책 계층을 추가합니다. 이러한 정책은 자주 사용됩니다:  

• 트래픽 인증 및 권한 부여: 서비스 메시에서는 mTLS(상호 TLS)를 사용하여 서비스 간의 통신을 암호화합니다. 또한 서비스가 서로 통신할 수 있는 정책을 설정하여 액세스 제어의 또 다른 계층을 추가할 수 있습니다.

• 트래픽 관리: 서비스 메시 정책으로 라우팅, 로드 밸런싱, 장애 조치를 제어합니다. 이를 통해 A/B 테스트, 카나리아 릴리스 또는 다른 서비스 버전으로 트래픽을 라우팅하는 등의 작업을 더 쉽게 수행할 수 있습니다.  

네트워크 정책과 달리 서비스 메시 정책은 애플리케이션 계층에서 작동하여 서비스 상호 작용 방식에 영향을 미칩니다. 이러한 정책은 서비스 간 트래픽을 관리하는 데 매우 중요합니다. 하지만 네트워크 정책과 겹치기 때문에 때때로 혼란스러울 수 있습니다.

7. 규정 준수 정책

규정 준수 정책은 시스템이 GDPR, HIPAA 또는 SOC 2와 같은 법적 또는 내부 규정 준수 요건을 충족하도록 데이터 관리, 액세스 및 운영 표준을 다룰 수 있습니다. 이러한 정책은 시스템의 여러 부분에서 중요한 역할을 하며 보안, 로깅 및 데이터 저장에 영향을 미칠 수 있습니다.

예를 들어, 규정 준수 정책에 따라 데이터를 특정 위치에만 저장(데이터 상주)하거나 감사 로그를 일정 기간 동안 보관하도록 요구할 수 있습니다. 쿠버네티스에서는 시스템이 표준을 충족하는지 실시간으로 지속적으로 모니터링하고 감사하여 이러한 정책을 시행하는 데 OPA 및 Kyverno와 같은 도구가 자주 사용됩니다.

규정 준수 정책은 의료 및 금융과 같이 엄격한 규제가 적용되는 산업에서 특히 중요합니다. 이러한 정책은 시스템의 여러 부분에 걸쳐 작동하고 보안 정책과 중복되는 경우가 많기 때문에 관리가 복잡해질 수 있습니다. 그럼에도 불구하고 시스템을 안전하고 체계적으로 유지하며 규정을 준수하는 데 매우 중요합니다.

8. 자동화 및 수명 주기 정책

자동화 정책은 인프라 리소스가 생성, 업데이트 또는 제거되는 시기와 방법을 제어합니다. 이러한 정책은 리소스 구성이 코드로 작성되고 CI/CD 파이프라인을 통해 관리되는 코드형 인프라(IaC)의 중요한 부분입니다.

예를 들어 자동화 정책은 리소스 자동 확장, 사용하지 않는 리소스 정리 또는 배포 수명 주기의 단계 관리와 같은 작업을 처리할 수 있습니다. 또한 CI/CD 파이프라인과 통합하여 빌드를 트리거하고 테스트를 실행하고 배포를 관리할 수 있습니다. 이렇게 하면 워크로드 변화에 실시간으로 적응할 수 있는 자체 관리 환경이 만들어집니다.

자동화 정책은 리소스 관리를 간소화하고 클라우드 네이티브 환경의 모범 사례를 보장할 수 있습니다. 그러나 리소스 관리 및 입학 관리 정책과 같은 다른 정책과 긴밀하게 상호 작용하여 복잡성을 가중시킬 수 있습니다.

아직 팔로우 중이신가요? "정책"의 중첩은 계속됩니다...

아직 당황스럽지 않으시다면, 여기 반전이 있습니다. 현재 많은 조직이 정책을 위한 정책을 가지고 있습니다.  

이를 "메타 정책"이라고 합니다. 누가 다른 정책을 만들고, 관리하고, 적용할 수 있는지에 대한 규칙을 설정하는 가드레일 역할을 합니다.  

예를 들어, 메타정책을 통해 특정 네트워크 정책을 만들 수 있는 팀이나 허용 제어 정책을 만들 수 있는 권한을 가진 사람을 결정할 수 있습니다. 이러한 정책은 종종 역할 기반 액세스 제어(RBAC)에 의존합니다.

대규모 시스템에서는 정책에 대한 RBAC 정책이 필수적입니다. 특정 관리자 또는 팀만 정책을 변경할 수 있도록 합니다. 이러한 '정책을 위한 정책'은 엄격한 RBAC 제어를 시행함으로써 다른 정책이 중요 인프라에 과도하게 영향을 미치거나 간섭하지 않도록 합니다.

최종 생각 정책 과부하를 통한 로드맵

클라우드 네이티브 및 분산 환경이 성장함에 따라 "정책" 의 개념은 계속 변화할 것입니다. 더 복잡하고 전문화되며 때로는 모순되기도 합니다.

정책 과부하를 방지하려면 명확한 명명 규칙을 사용하고, 각 정책 유형을 정의하는 문서를 작성하며, 정책 도구를 잘 활용하는 것이 중요합니다.

다음에 기술 컨퍼런스에서 "정책을 듣게 된다면" 잠시 시간을 내어 "어느 정책인가요?!" 많은 혼란이나 심지어 홀을 가로지르는 전력 질주에서 벗어날 수 있습니다!

지금 바로 연락하여 Illumio가 클라우드, 엔드포인트, 데이터센터 환경 전반에서 네트워크 보안 정책을 간소화하는 방법을 알아보세요.