다음을 통해 공유

작업 보호

운영 보안은 Kubernetes 클러스터에 대한 제어를 유지하고 새로운 위협에 대응하는 데 중요합니다. 이 문서에서는 액세스 관리, 정책 적용, 활동 모니터링 및 인시던트 대응에 대한 모범 사례를 설명합니다. 강력한 운영 제어를 구현하면 권한 있는 사용자 및 프로세스만 클러스터 및 워크로드를 변경할 수 있도록 할 수 있습니다.

Azure 컨트롤 플레인을 사용하여 클러스터를 관리할 수 있는 사용자 제어

에지 클러스터의 Azure Arc 클라우드 관리를 사용하도록 설정하는 구독 및 리소스를 포함하여 Azure 컨트롤 플레인에 대한 액세스를 제어하는 것이 중요합니다. 다단계 인증 및 조건부 액세스를 포함하여 Azure 액세스 제어 모범 사례를 검토하고 구현합니다. Azure RBAC를 사용하여 다른 Azure 클라우드 리소스에 대한 액세스를 제어하는 데 이미 사용할 수 있는 것과 동일한 방식으로 클러스터를 사용하여 수행할 수 있는 작업을 제어할 수 있습니다.

또한 Microsoft에서 생성된 인증서는 에지 클러스터와 Azure 컨트롤 플레인 간의 연결을 보호하는 데 사용됩니다. 이러한 인증서는 Kubernetes 비밀로 저장되므로 Kubernetes 비밀 저장소 자체를 암호화하는 것이 중요합니다.

역할 기반 액세스 제어(RBAC)를 사용하여 클러스터에 배포할 수 있는 권한을 제어하세요.

Kubernetes 워크로드를 배포하고 모니터링할 수 있는 수단인 API 서버(Kubernetes 컨트롤 플레인) 자체에 대한 액세스를 제어하는 것도 중요합니다.

워크로드에서 API 서버에 대한 비인간적인 액세스의 경우 Kubernetes의 기본 제공 RBAC를 사용하여 필요한 특정 서비스 계정에만 권한을 부여합니다. 이러한 서비스 계정 발급 및 보호에 대한 조언도 참조하세요.

API 서버에 대한 사용자 액세스의 경우 Kubernetes에는 기본 제공 사용자 계정이 없습니다. 따라서 Microsoft Entra ID와 같은 외부 사용자 계정 서비스와 통합하는 것이 좋습니다. 그런 다음 이러한 ID를 사용하여 네임스페이스를 수행할 수 있는 사용자를 제어하는 권한 부여 정책을 만들 수 있습니다. Kubernetes의 기본 제공 RBAC를 사용하거나 Azure RBAC를 사용하여 이러한 정책을 작성할 수 있습니다. 클라우드 및 에지 리소스를 모두 포함하는 모든 사용자 권한 부여 정책을 한 곳에서 일관되게 관리하고 감사하려는 경우 Azure RBAC를 사용하는 것이 좋습니다. Azure Local에서 Azure Arc에서 사용하도록 설정된 AKS를 실행 하거나 사용자 고유의 클러스터를 연결하는 경우 Azure RBAC를 쉽게 사용할 수 있습니다. 그런 다음 사용자는 Entra ID 계정을 사용하여 직접 또는 "클러스터 연결" 기능을 사용하여 Azure 프록시를 통해 클러스터(해당 API 서버)에 액세스할 수 있습니다. 필요한 최소 권한이 있는 역할을 각 사용자 또는 워크로드에 할당하는 "최소 권한" 접근 방식을 사용하는 것이 좋습니다.

일반적으로 개발, 테스트 및 프로덕션 클러스터를 분리하는 표준 모범 사례를 따릅니다. 그리고 GitOps 접근 방식을 사용하여 클러스터에 대한 프로덕션 배포를 보다 안정적이고 안전하게 관리할 수 있는지 고려합니다. 이 방법을 따르는 경우 배포를 정의하는 데 사용되는 기본 원본 Git 리포지토리 및 분기에서 변경(끌어오기 요청)에 대해 유사한 강력한 역할 기반 액세스 제어를 구현하는 것도 중요합니다.

마지막으로 Azure Local에서 Azure Arc에서 사용하도록 설정된 AKS를 실행하는 경우 전체 관리자 액세스에 대한 관리 클라이언트 인증서를 다운로드할 수도 있습니다. 일반적으로 이 인증서를 사용할 필요는 없으므로 필요한 경우에만 다운로드합니다. 예를 들어 다른 방법으로는 조사할 수 없는 문제를 진단합니다. 또한 이 방법은 Entra ID 계정 및 설정한 사용자별 정책을 사용하지 않으므로 주의해서 사용해야 합니다. 또한 클라이언트 인증서를 신중하게 저장한 다음 더 이상 필요하지 않은 경우 삭제해야 합니다.

참고문헌

Kubernetes용 Azure Policy를 사용하여 컨테이너를 배포하고 실행할 때 보안 컨테이너 수명 주기를 따릅니다.

배포 단계를 통해 Microsoft Containers Secure Supply Chain 프레임워크 를 계속 따릅니다. ( 획득, 카탈로그 및 빌드 단계에 대한 지침도 참조하세요.) 이 프레임워크는 Azure Container Registry와 같은 자체 신뢰할 수 있는 레지스트리에서만 배포하는 데 도움이 됩니다. 레지스트리의 액세스 제어 메커니즘을 사용하여 신뢰할 수 있는 클러스터만 중요한 정보를 포함할 수 있는 컨테이너를 끌어오도록 합니다. Azure Container Registry는 RBAC(역할 기반 액세스 제어) 와 ABAC(특성 기반 액세스 제어) 를 모두 지원하여 특정 리포지토리에 대한 추가 범위 할당을 지원합니다.

또한 Azure Policy를 통해 컨테이너 보안 위생에 대한 모범 사례 표준을 적용합니다. 예를 들어 Azure Policy의 기본 제공 정의를 사용하여 모든 Pod가 낮은 코드 방식으로 Pod 보안 표준을 충족하는지 확인할 수 있습니다. Gatekeeper를 확장하는 Azure Policy 확장을 에지 Kubernetes 클러스터에 배포하여 대규모 Pod 기반 보안 적용을 적용할 수도 있습니다. 먼저 "감사" 모드에서 정책 할당을 적용하는 것이 좋습니다. 이 모드는 Kubernetes별 리소스, 정책별 세분성에서 비규격 결과의 집계 목록을 제공하므로 실행 중인 배포와 관련된 기존 문제를 먼저 찾아서 수정할 수 있습니다. 사용자 환경에서 비준수 위반을 수정한 후 정책 할당을 "거부" 모드로 업데이트할 수 있습니다. Azure Policy의 풍부한 안전 배포 메커니즘은 리소스 간에 이 정책 적용을 점진적으로 롤아웃합니다. 적용 모드에서 정책을 적용하면 추가 편차를 적극적으로 방지할 수 있습니다.

참고문헌

컨트롤 플레인 변경 모니터링을 비롯한 새로운 위협 감지

클러스터에서 발생하는 위협을 감지할 수 있는 방법이 있는지 확인합니다.

Defender for Containers 확장을 에지의 Kubernetes 클러스터에 배포할 수 있습니다. 이 확장에는 로그를 수집하고 Defender for Cloud로 보내는 센서 가 포함되어 있습니다. 일단 그곳에 도착하면, 공격을 나타낼 수 있는 비정상적인 동작을 분석하거나 가능한 인시던트 후 포렌식에 사용될 수 있습니다. 어떤 클러스터 유형에서 기능이 미리 보기 또는 GA 릴리스로 지원되는지 확인하려면 지원 매트릭스를 참조하세요. 따라서 Defender for Cloud는 Microsoft Defender XDR 인시던트 검색 및 대응 솔루션의 일부로 분석을 위한 이벤트를 보낼 수 있습니다.

Azure Local의 Azure Arc에서 사용하도록 설정된 AKS에서 실행하는 경우 Kubernetes 감사 로그를 Azure Monitor(Log Analytics 작업 영역)로 보내도록 구성할 수도 있습니다. 또한 워크로드 자체를 모니터링하기 위한 관련 조언을 따릅니다. 또한 안정성, 비용 최적화, 성능 및 보안을 다루는 클러스터 모니터링 에 대한 모범 사례를 살펴봅니다.

모니터링 외에도 인시던트 대응 계획을 수립하고 이를 사용하여 연습합니다. 이러한 계획의 세부 정보는 전체 배포 환경 및 사용하는 보안 작업 도구에 따라 크게 달라집니다. 자세한 내용은 이 지침을 참조하세요. 그러나 최소한 클러스터의 상태를 유지하는 방법(감사 로그를 보관하고 의심스러운 상태의 스냅샷을 찍는 방법) 및 정상 작동이 확인된 상태로 복구하는 방법을 생각해 보세요.

참고문헌

배포 전략을 사용하여 가동 중지 시간 0 업데이트 달성

중요한 보안 업데이트는 긴급하게 출시되더라도 워크로드의 안정성과 가용성을 손상해서는 안 됩니다. 환경에서 고가용성을 유지하는 데 가장 적합한 Kubernetes 배포 전략을 선택합니다. 또한 준비 상태 및 활동성 프로브를 구현하여 Kubernetes가 배포를 유지 관리하는 워크로드의 상태에 대해 더 잘 알아볼 수 있도록 하는 것이 좋습니다. 수신 부하 분산 장치의 점진적 출시 및 트래픽 관리 정책과 결합하면 Kubernetes를 사용하여 애플리케이션의 가용성을 방해하지 않고 업데이트를 구동할 수 있습니다.

다음 단계