가장 일반적인 Kubernetes 보안 문제와 이를 완화할 수 있는 방법

Kubernetes와 컨테이너는 다음 세 가지를 약속합니다.

• 더 빠른 애플리케이션 개발 및 출시.
• 더 빠른 버그 수정.
• 기능 속도가 향상되었습니다.

그러나 보안이 손상되는 대가를 치러야 하는 경우가 많으며 이는 웹 개발 기술에서 허용되지 않는 것입니다.

Kubernetes 보안 상태를 실현하기 위해 2020년 말에 StackRox에서 실시한 설문 조사에서 다음 두 가지 요소가 있습니다.

• 설문 조사 참가자의 90%는 지난 12개월 동안 컨테이너 및 Kubernetes와 관련된 보안 사고에 직면했다고 보고했습니다.
• 참가자의 44%는 Kubernetes와 관련된 보안 문제로 인해 애플리케이션 출시를 연기해야 ​​했습니다.

이러한 보안 문제의 가장 일반적인 이유는 무엇입니까?

Kubernetes와 관련된 가장 일반적인 보안 문제

1. 잘못된 구성

설문 조사에 따르면 잘못된 구성으로 인한 노출이 컨테이너 및 Kubernetes 환경의 보안에서 가장 흔한 위험인 것으로 나타났습니다.

Kubernetes를 사용하여 컨테이너화된 앱을 만들 때 구성 관리는 보안 실무자에게 가장 큰 위험입니다.

이는 주로 시장이 취약성 스캐닝 도구로 가득 차 있지만 구성 관리는 여전히 인간의 고려에 크게 의존하기 때문입니다.

다음은 보안이 손상되지 않도록 컨테이너화된 앱의 일부 공통 구성 요소를 구성하는 방법에 대한 몇 가지 조언입니다.

이미지:

절대적으로 필요하지 않은 소프트웨어는 사용하지 마십시오. 여기에는 패키지 관리자, 네트워크 도구, curl 또는 Unix 셸과 같은 클라이언트가 포함됩니다.

소프트웨어를 사용하면 보안 위험이 추가된다는 점을 기억하십시오. 또한 신뢰할 수 있는 출처의 이미지만 사용하십시오.

비밀:

이미지에 비밀을 넣거나 불필요하게 노출하지 마십시오.

안전한 방법으로 신뢰할 수 있는 비밀 관리 도구를 사용하여 배포가 필요한 경우에만 비밀을 탑재하도록 합니다.

네임스페이스:

네임스페이스를 아낌없이 사용합니다. Kubernetes 및 네트워크 정책의 경계 역할을 합니다. 네임스페이스를 사용하면 공격의 영향을 제한할 수 있으며 실수와 공격이 포함될 수 있으므로 확산되어 더 많은 파괴를 일으킬 수 없습니다.

런타임 권한:

단 하나의 권한 규칙이 있습니다. 가장 적은 수의 권한만 허용하여 소프트웨어를 가장 안전하게 만들 수 있습니다.

네트워크 정책

기본 설정에 따라 Pod는 Kubernetes에서 서로 독립적으로 통신할 수 있습니다. 그러나 포드의 상호 작용을 제한하는 네트워크 정책을 구현하는 것이 좋습니다. 이렇게 하면 위협이 컨테이너와 전체 앱에 퍼지는 것을 방지할 수 있습니다.

영구 스토리지

영구 저장소의 구성 및 사용에 대한 적절한 가시성이 있어야 합니다. 이것은 임시 컨테이너 설정에서 유일한 영구 벡터이기 때문입니다.

컨트롤 플레인

Kubernetes 클러스터를 직접 관리하는 경우 컨트롤 플레인을 구성하는 것이 매우 중요합니다. 일부 클러스터는 글로벌 결정을 내릴 수 있고 클러스터가 감염되면 전체 생태계를 손상시킬 수 있기 때문입니다.

이러한 문제와 기타 다양한 구성 관련 보안 문제를 완화하는 가장 좋은 방법은 수동 및 자동화된 노력의 조합을 사용하여 구성이 Kubernetes의 보안과 결과적으로 일부인 소프트웨어를 보장하는 방식으로 수행되도록 하는 것입니다. 의.

2. 취약점

지난 몇 년 동안 Kubernetes 및 기타 컨테이너에서 다양한 취약점이 발견되어 악용되었습니다.

가장 일반적인 취약점 악용은 다음과 같습니다.

• 암호화 마이닝.
• 맬웨어 설치.
• 권한 상승.
• 호스트 액세스.

취약성을 관리하기 위한 효과적인 접근 방식은 컨테이너의 수명 주기 동안 계속되어야 하며 다음을 포함해야 합니다.

• 설치된 운영 체제의 취약점을 포함하여 이미지의 취약점을 식별하고 해결합니다.
• 사용 중인 프로그래밍 언어의 런타임 라이브러리에서 모든 취약점을 탐지하고 완화합니다.
• 위험한 취약점이 있는 이미지가 프로덕션에서 액세스할 수 있는 컨테이너 레지스트리에 도달하는 것을 방지하기 위한 조치를 취합니다.
• 일정 수준 이상의 보안 위험이 있는 위협을 차단하기 위한 조치를 취합니다.
• 취약한 컨테이너 구성 요소가 예약되지 않도록 Kubernetes 클러스터에서 타사 승인 컨트롤러를 사용합니다.

3. 런타임 위협

Kubernetes 보안의 모든 문제를 완화하면 런타임 단계에 고유한 보안 위협 세트가 있습니다.

보안을 강조하고 가능한 모든 방법으로 위험을 최소화하더라도 런타임에 적의 다양한 위협이 있을 수 있습니다.

이러한 위협을 완화하기 위해 수행할 수 있는 몇 가지 작업은 다음과 같습니다.

런타임 활동 모니터링:

보안과 가장 관련성이 높은 컨테이너 활동으로 모니터링 프로세스를 시작합니다. 여기에는 프로세스 활동, 컨테이너화된 서비스 내부 및 전체의 네트워크 통신, 외부 서버 및 클라이언트와의 통신이 포함됩니다.

선언적 데이터 활용

빌드 및 배포 시간 정보를 사용하여 관찰된 활동과 예상되는 활동 간의 차이를 평가하여 의심스러운 활동이 있는지 확인합니다.

네트워크 통신을 제한적으로 유지

런타임은 허용된 네트워크 트래픽의 종류와 시스템을 실행하는 데 필요한 트래픽의 종류의 차이를 확인할 수 있는 시간입니다. 이것은 Kubernetes 보안에 위협이 될 수 있는 불필요한 통신을 제거하는 데 사용할 수 있는 기회입니다.

프로세스를 면밀히 관찰

응용 프로그램의 적절한 기능을 위해 실행되는 모든 프로세스를 알기 위해 일정 기간 동안 응용 프로그램을 관찰하십시오. 모든 필수 프로세스의 목록을 만들고 응용 프로그램을 무작위로 확인하여 일반적인 프로세스가 아닌 프로세스가 실행되고 있는지 확인하십시오.

4. 준법감시 실패

Kubernetes 및 컨테이너 보안을 보장하는 주요 사항 중 하나는 규정 준수입니다. 소프트웨어 개발 수명 주기에서 보안이 적절히 강조되지 않으면 규정 준수 감사에 실패할 수 있습니다.

Kubernetes 및 컨테이너 보안에 사용할 수 있는 수많은 규정 준수 표준이 있습니다.

PCI-DSS, HIPAA 및 SOC 2는 산업별 규정 준수 표준입니다.

이와 관련하여 저지르는 주요 실수 중 하나는 준수 감사를 처음부터 SDLC의 일부로 만들지 않거나 런타임 시에만 고려하는 것입니다. 소프트웨어의 모든 항목이 규정을 준수하는지 확인하려면:

• 처음부터 규정 준수를 SDLC의 일부로 만드십시오.
• 소프트웨어 구성 요소를 준수하도록 하려면 업계 표준을 사용하십시오.