자율 운영자를 사용한 쿠버네티스 취약점 탐색하기

첫 번째 중요 취약점 의 취약점이 이달 초에 공개되었습니다. 이 취약점은 1.0.0 이상의 모든 Kubernetes 버전에 영향을 미치며, 3.0.0 이상의 RedHat OpenShift 플랫폼 버전에도 영향을 미칩니다.

이 게시물에서는 원인, 완화 방법 및 이것이 Couchbase 자율 운영자에 미치는 영향에 대해 살펴봅니다.

취약점

사용자는 일반적으로 쿠버네티스 파드에 연결할 때 다음 명령을 사용합니다:

도커 컨테이너 관리 제품군 사용자에게는 매우 익숙하게 보일 것입니다. 그 이유는 명령이 먼저 역방향 프록시 역할을 하는 Kubernetes API로 전송되기 때문입니다. 리버스 프록시는 요청된 파드가 상주하는 노드에서 실행 중인 Kubernetes 에이전트로 요청을 전달합니다. 마지막으로 이 명령은 도커 컨테이너에 직접 연결하는 데 사용됩니다.

원격 실행 명령에 오류가 발생하면 역방향 프록시에서 취약점이 노출됩니다. 오류가 발생하면 프록시에서 다운스트림 서비스에 대한 연결이 열린 상태로 유지됩니다. 이는 사용자가 자신의 권한을 쿠버네티스 클러스터 관리자의 권한으로 에스컬레이션할 수 있는 방법을 제공합니다. 사용자는 역할 기반 액세스 제어를 통해 명령을 수행할 수 있어야 합니다.

그러면 관리자 수준의 권한을 가진 사용자는 손상된 Kubernetes 노드에서 실행 중인 모든 컨테이너에 연결할 수 있습니다. 이렇게 하면 컨테이너에 마운트된 모든 시크릿(일반적으로 사용자 이름, 비밀번호, TLS 개인 키 등) 및 데이터 볼륨에 액세스할 수 있습니다. 컨테이너가 상승된(루트) 권한으로 실행되는 경우 이 문제는 더욱 심각합니다. 또한 컨테이너에 읽기/쓰기 모드로 마운트된 호스트 파일 시스템도 있을 수 있습니다.

두 번째 변종은 다시 동일한 기본 역방향 프록시 취약점에 의존합니다. 첫 번째 변종에서는 권한 상승이 수행되기 전에 사용자가 인증을 받아야 하고 컨테이너에서 명령을 실행할 수 있는 액세스 권한이 있어야 합니다. 두 번째 변종에서는 관리 액세스 권한을 얻기 위해 인증이 전혀 필요하지 않습니다. 이 취약점의 범위는 서비스 브로커의 수정으로 제한됩니다. 이러한 서비스는 애플리케이션에서 발견하여 사용할 수 있는 관리형 서비스입니다.

완화 조치

취약점의 첫 번째 변종의 경우, 사용 권한을 제거하여 사용자의 권한 상승을 방지할 수 있습니다. exec, 첨부 그리고 포트 포워드 명령어를 사용할 수 있다. 이러한 권한은 대부분의 설치에서 기본적으로 부여됩니다. 그러나 이 명령어는 일반적으로 대부분의 환경에서 디버깅 및 테스트 목적으로 필요하므로 액세스를 비활성화하는 것이 정답이 아닐 수 있습니다.

따라서 모든 취약점을 방지하는 가장 좋은 방법은 취약점이 패치된 버전으로 Kubernetes 클러스터를 업그레이드하는 것입니다. 패치된 버전은 쿠버네티스 1.10.11, 1.11.5 및 1.12.3부터 시작됩니다.

카우치베이스 자율 운영자는 쿠버네티스 버전 1.11.0 이상에서 지원됩니다. 가능한 한 빠른 시일 내에 해당 패치 버전 중 하나로 업그레이드하는 것이 좋습니다. 자율 운영자 자체는 이러한 취약점이나 수정 사항의 영향을 받지 않지만, 생성된 Couchbase 서버 파드는 첫 번째 취약점의 영향을 받아 데이터 무결성이 손상될 수 있습니다.

자율 운영자 고려 사항

심각한 취약점이 발견되는 것은 결코 좋은 일이 아니지만, 저희는 이러한 상황에 대비하고 있습니다. 전체 Kubernetes 업그레이드 지침은 오퍼레이터 1.1.0 문서이 게시물에서 더 자세히 설명하겠습니다.

스테이트풀 서비스로서, Couchbase 데이터 플랫폼의 데이터 무결성을 유지하기 위해 Kubernetes 클러스터를 업그레이드할 때는 주의가 필요합니다.

많은 쿠버네티스 관리 애플리케이션에서 사용하는 표준 롤링 업그레이드 방식은 각 워커 노드를 순서대로 업그레이드한다. 단일 노드를 업그레이드하려면 먼저 파드를 퇴거(삭제)합니다. 파드가 디플로이먼트와 같은 애플리케이션의 일부인 경우, 애플리케이션을 관리하는 컨트롤러가 모든 퇴거된 파드를 다시 생성한다. 이는 올바른 스케일링을 복원하기 위한 것이다. 퇴거 후 쿠버네티스 에이전트를 업그레이드할 수 있다. 기본 호스트가 재부팅될 수 있다. 이때는 운영 체제 패치를 적용하기에 좋은 시기입니다. 마지막으로 노드를 클러스터에 다시 추가할 수 있습니다.

상태 비저장 서비스의 경우, 파드를 다시 생성하고 서비스 풀에 다시 추가하는 데 몇 초 밖에 걸리지 않습니다. Couchbase 서버와 같은 상태 저장 애플리케이션의 경우 이보다 훨씬 더 오래 걸릴 수 있습니다.

퇴거 중에는 어떤 일이 발생하나요?

노드가 3개인 Couchbase 클러스터를 예로 들어보겠습니다. Couchbase 클러스터에는 단일 복제본이 있는 단일 버킷이 포함되어 있습니다.

첫 번째 카우치베이스 파드가 제거되면 자율 운영자는 해당 파드가 다운된 것을 감지하고 페일오버가 발생할 때까지 기다립니다. 장애 조치는 복제본에서 데이터의 가용성을 복원합니다. 페일오버가 수행되면 자율 운영자는 새 포드를 생성하고 Couchbase 클러스터 전체에서 데이터 리밸런싱을 시작합니다. 이렇게 하면 올바른 복제본 수가 복원됩니다. 이 과정에서 새 파드를 수용하기 위해 추가 Kubernetes 노드가 필요하다는 점에 유의해야 합니다.

3개의 노드 중 하나가 손실되었으므로 버킷에 포함된 66%의 문서는 단 하나의 복제본으로만 성능이 저하됩니다. 다음 표는 6개의 마스터 문서(굵은 글씨로 표시)와 그 복제본이 있는 위치를 보여줍니다. 서버 1이 퇴출되는 경우, 문서 A, B, D, E에는 하나의 복제본만 남게 됩니다.

리밸런싱이 진행되는 동안, Kubernetes 업그레이드 프로세스가 다른 Couchbase 파드를 퇴거시키는 것을 막을 수 있는 방법은 없습니다. 이런 일이 허용되면 최대 33%의 데이터가 복제본이 없어 손실될 위험이 있습니다. 위의 예에서 서버 2가 퇴거되면 문서 A와 D를 복구할 수 없게 됩니다.

따라서 쿠버네티스 노드를 퇴출하는 방법과 시기를 제어하는 것이 중요합니다. 카우치베이스 서버 파드가 퇴거되면 자율 운영자가 대체 파드를 생성하도록 허용하고 다음 쿠버네티스 노드를 업그레이드하기 전에 데이터가 완전히 리밸런싱되도록 허용해야 합니다.

자율 운영자 모범 사례

Couchbase 클러스터를 구성할 때 파드 선호도 방지 기능을 사용하는 것이 좋습니다. 이 기능은 동일한 Couchbase 클러스터의 두 개의 Couchbase 서버 파드가 동일한 Kubernetes 노드에 상주할 수 없도록 합니다. 이렇게 하면 한 번에 최대 하나의 복제본만 손실될 수 있습니다.

또한 영구 볼륨 사용을 적극 권장합니다. In 마지막 게시물 에서 데이터 손실을 방지하고 제품을 지원하기 위해 영구 볼륨 사용을 의무화하는 방법을 설명했습니다. 주요 이점은 마지막 섹션에 제공된 예제에서 데이터가 손실되지 않는다는 것입니다.

자율 운영자는 새 파드를 다시 생성하고 기존 데이터 볼륨을 재사용할 수 있습니다. 장애 조치 이후 업데이트된 문서만 대체 파드에 복제하면 되므로 이 클러스터에서 데이터 리밸런싱이 훨씬 빨라집니다.

퍼시스턴트 볼륨이 활성화되어 있어도 여러 개의 파드가 연속적으로 빠르게 제거될 수 있습니다. 이로 인해 자율 운영자가 데이터를 복원할 때까지 특정 문서를 일시적으로 사용할 수 없게 될 수 있습니다.

미래를 바라보며

우리는 전체 Kubernetes 업그레이드 경험이 원활하게 이루어지기를 바랍니다. 이는 바로 Kubernetes 플랫폼이나 운영 체제에서 버그가 발견될 수 있기 때문입니다. 애플리케이션의 안정성과 보안을 보장하기 위해 이러한 버그를 패치해야 합니다.

영구 볼륨이 해답의 일부이기는 하지만 완전한 해결책은 아닙니다. 여전히 문서를 사용할 수 없는 상황이 발생할 수 있습니다. 이 문제를 해결하기 위해 장애 복구 기간 동안만 문서 중단을 완화하는 개선된 기능이 Autonomous Operator 1.2.0에 추가된다는 기쁜 소식을 알려드립니다.

쿠버네티스 파드 중단 예산을 활용하면, 자율 운영자가 한 번에 퇴출할 수 있는 파드 수를 정확하게 제어할 수 있습니다. 이렇게 하면 한 번에 여러 개의 데이터 복제본이 퇴출되는 것을 방지할 수 있습니다.

이 외에도, 중단 예산에서 사용하는 포드 준비 상태 확인은 Couchbase 서버 포드가 모두 살아 있고 모든 데이터가 클러스터 전체에 완전히 복제되었는지 여부를 인식하도록 개선되었습니다. 이를 통해 자율 운영자는 새로운 퇴거가 허용되는 시점을 정확하게 제어할 수 있습니다.

결론

Couchbase Autonomous Operator는 Couchbase 데이터 플랫폼의 배포와 관리를 간소화하기 위한 제품으로만 설계된 것이 아닙니다. 관리형 퍼블릭 클라우드 플랫폼에서 운영할 때 고유한 과제가 있다는 점을 더 넓게 바라보고 있습니다. 저희 팀은 Atlassian이 통제하는 상황과 통제하지 않는 상황 모두에서 데이터를 보호하고 데이터의 고가용성을 제공하기 위해 지속적으로 노력하고 있습니다.