오늘날의 분산 시스템의 정책 과부하 해소를 위한 가이드

KubeCon에 참석하여 “정책”에 관한 세션에 참석해 보시기 바랍니다.그곳에 도착했을 때 “이게 실제로 어떤 정책을 다루고 있는 걸까?” 하고 궁금해하더라도 놀라지 마세요.

최근에 솔트레이크시티의 KubeCon, 제목에서 “정책”이 두드러지는 세션 사이를 전력 질주하고 있었습니다.하지만 연사마다 이 단어는 전혀 다른 의미를 지녔습니다.

레이블 기반 네트워크 정책을 주로 다루는 사람으로서 저는 “이 정책 세션은 네트워크 정책, 어드미션 컨트롤러 또는 규정 준수에 관한 것인가요?” 라고 미리 강연자를 만나야 하는 경우가 많았습니다.

이러한 교환을 통해 오늘날의 클라우드 네이티브 및 분산 컴퓨팅 에코시스템에서 점점 더 많은 문제가 발생하고 있습니다.“정책”이라는 용어는 너무 광범위하게 사용되기 때문에 사실상 그 자체로 추상화라고 할 수 있습니다.

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

1.네트워크 정책

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

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

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

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

2.어드미션 컨트롤러 정책

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

예를 들어, 어드미션 컨트롤러 정책은 다음을 수행할 수 있습니다.

• 리소스 제한 자동 적용

• 배포에 레이블 추가

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

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

3.OPA 및 카이베르노 정책

OPA와 Kyverno 정책은 단순한 어드미션 컨트롤러인가요, 아니면 그 이상인가요?

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

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

• 카이베르노 쿠버네티스를 위해 특별히 만들어진 정책 엔진입니다.YAML에서 정책을 정의하는 더 간단한 방법입니다.많은 사람들이 쿠버네티스를 구성할 때 선호합니다.네이티브 쿠버네티스 오브젝트와 잘 작동하므로 정책을 쉽게 구축하고 적용할 수 있습니다.

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

• 라이프사이클 관리

• 유효성 검사

• 맞춤형 규정 준수 검사

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

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

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

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

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

이러한 정책은 관리자가 리소스의 균형을 유지하는 데 도움이 됩니다. 이는 사용자가 많은 시스템이나 동적으로 확장되는 앱에서 특히 중요합니다.하지만 이러한 정책을 관리하는 것은 어려울 수 있습니다.자동화 및 승인 제어와 같은 다른 정책과 겹치는 경우가 많습니다.

5.포드 보안 정책 (PSP)

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

하지만 쿠버네티스에서 PSP는 단계적으로 폐지되고 있습니다.포드 보안 표준 (PSS) 과 같은 새로운 옵션과 OPA 및 Kyverno와 같은 외부 도구로 대체되고 있습니다.

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

6.서비스 메시 정책

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

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

• 트래픽 관리: 서비스 메시 정책은 라우팅, 로드 밸런싱 및 페일오버를 제어합니다.따라서 A/B 테스트, 카나리아 릴리스 또는 다른 서비스 버전으로 트래픽 라우팅과 같은 작업을 더 쉽게 수행할 수 있습니다.

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

7.규정 준수 정책

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

예를 들어 규정 준수 정책에 따라 데이터를 특정 위치에만 저장 (데이터 레지던시) 하거나 감사 로그를 일정 기간 보관하도록 요구할 수 있습니다.Kubernetes에서는 OPA 및 Kyverno와 같은 도구를 사용하여 시스템을 실시간으로 지속적으로 모니터링하고 감사하여 표준을 충족하는지 확인함으로써 이러한 정책을 적용하는 경우가 많습니다.

규정 준수 정책은 의료 및 금융과 같이 규제가 엄격한 산업에서 특히 중요합니다.이러한 정책은 시스템의 여러 부분에서 작동하고 보안 정책과 겹치는 경우가 많기 때문에 관리가 복잡해질 수 있습니다.그럼에도 불구하고 시스템의 보안, 체계화 및 규정 준수를 보장하는 데는 매우 중요합니다.

8.자동화 및 라이프사이클 정책

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

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

자동화 정책은 리소스 관리를 간소화하고 클라우드 네이티브 환경에서 모범 사례를 보장할 수 있습니다.그러나 이러한 정책은 리소스 관리 및 승인 제어를 위한 정책과 같은 다른 정책과 긴밀하게 상호 작용하므로 복잡성이 가중될 수 있습니다.

아직도 팔로우 중이세요?“정책”의 중복은 계속되고 있습니다...

아직 압도되지 않았다면 여기에 반전이 있습니다.현재 많은 조직이 정책 정책을 가지고 있습니다.

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

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

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

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

클라우드 네이티브 및 분산 환경이 성장함에 따라 “정책”이라는 개념은 계속해서 변화할 것입니다.이러한 환경은 더욱 복잡해지고 전문화되며 때로는 모순될 수도 있습니다.

정책 오버로드를 피하려면 명확한 이름 지정 규칙을 사용하고, 각 정책 유형을 정의하는 문서를 만들고, 정책 도구를 잘 활용하는 것이 중요합니다.

다음에 기술 컨퍼런스에서 “정책”이라는 말을 들으면 잠시 시간을 내어 “어떤 정책인가요?!” 라고 물어보세요.이렇게 하면 많은 혼란에서 벗어날 수 있습니다. 심지어 크로스 홀 스프린트도 할 수 있답니다!

오늘 저희에게 연락하세요 Illumio가 클라우드, 엔드포인트 및 데이터 센터 환경 전반에서 네트워크 보안 정책을 간소화하는 방법을 알아보십시오.