Kubernetes 클러스터의 구멍을 수정합니다. DevOpsConf의 보고 및 기록

Southbridge 솔루션 설계자이자 Slurm 교사인 Pavel Selivanov가 DevOpsConf 2019에서 프레젠테이션을 했습니다. 이 강연은 Kubernetes "Slurm Mega"에 대한 심층 과정 주제 중 하나입니다.

Slurm 기본: Kubernetes 소개 18월 20~XNUMX일 모스크바에서 개최됩니다.
Slurm Mega: Kubernetes의 내부 살펴보기 — 모스크바, 22월 24~XNUMX일.
Slurm Online: 두 Kubernetes 과정 모두 항상 이용 가능합니다.

컷 아래에는 보고서의 사본이 있습니다.

안녕하세요, 동료들과 그들에게 공감하는 사람들입니다. 오늘은 안전에 대해 이야기하겠습니다.

오늘 복도에 경비원이 많이 있는 것을 보니 보안 분야의 용어를 사용하는 것이 귀하의 관례와 정확히 일치하지 않는다면 미리 사과드립니다.

약 XNUMX개월 전에 저는 공개 Kubernetes 클러스터 하나를 발견했습니다. 공개는 n번째 네임스페이스가 있다는 의미이며, 이러한 네임스페이스에는 해당 네임스페이스에 격리된 사용자가 있습니다. 이러한 사용자는 모두 서로 다른 회사에 속해 있습니다. 글쎄요, 이 클러스터는 CDN으로 사용되어야 한다고 가정했습니다. 즉, 그들은 당신에게 클러스터를 제공하고, 거기에 사용자를 제공하고, 당신은 네임스페이스로 가서 프런트를 배포합니다.

이전 회사에서는 그러한 서비스를 판매하려고 했습니다. 그리고 이 솔루션이 적합한지 아닌지 확인하기 위해 클러스터를 찔러보라는 요청을 받았습니다.

나는이 클러스터에 왔습니다. 나에게는 제한된 권리와 제한된 네임스페이스가 주어졌습니다. 거기 사람들은 안전이 무엇인지 이해했습니다. 그들은 Kubernetes의 역할 기반 액세스 제어(RBAC)에 대해 읽었고 배포와 별도로 포드를 시작할 수 없도록 이를 왜곡했습니다. 배포 없이 Pod를 시작하여 해결하려고 했던 문제는 기억나지 않지만 꼭 Pod만 시작하고 싶었습니다. 행운을 빌기 위해 나는 클러스터에서 내가 가진 권리가 무엇인지, 내가 할 수 있는 것은 무엇인지, 무엇을 할 수 없는지, 클러스터에서 무엇을 망쳤는지 살펴보기로 결정했습니다. 동시에 RBAC에서 잘못 구성한 내용도 알려 드리겠습니다.

XNUMX분 만에 해당 클러스터의 관리자를 받고, 모든 인접 네임스페이스를 살펴보고, 거기에서 이미 서비스를 구매하고 배포한 회사의 실행 중인 프로덕션 프런트를 보았습니다. 나는 누군가의 앞에 가서 메인 페이지에 욕설을 올리는 것을 간신히 멈출 수 있었습니다.

제가 이 일을 어떻게 했는지, 그리고 이로부터 자신을 보호하는 방법을 예를 들어 말씀드리겠습니다.

하지만 먼저 제 소개를 하겠습니다. 제 이름은 파벨 셀리바노프입니다. 저는 Southbridge의 건축가입니다. 저는 Kubernetes, DevOps 및 모든 종류의 멋진 것들을 이해합니다. 사우스브리지 엔지니어들과 저는 이 모든 것을 구축하고 컨설팅도 하고 있습니다.

주요 활동 외에도 최근에는 Slurms라는 프로젝트를 시작했습니다. 우리는 Kubernetes를 사용하여 작업할 수 있는 능력을 대중에게 알리고 다른 사람들에게도 K8을 사용하도록 가르치려고 노력하고 있습니다.

오늘은 무슨 이야기를 할까요? 보고서의 주제는 분명합니다 - Kubernetes 클러스터의 보안에 관한 것입니다. 하지만 저는이 주제가 매우 크다는 점을 즉시 말하고 싶습니다. 따라서 제가 확실히 이야기하지 않을 내용을 즉시 명확히하고 싶습니다. 인터넷에서 이미 수백 번이나 사용된 진부한 용어에 대해서는 이야기하지 않겠습니다. 모든 종류의 RBAC 및 인증서.

Kubernetes 클러스터의 보안과 관련하여 저와 제 동료들이 겪는 고통에 대해 이야기하겠습니다. 우리는 Kubernetes 클러스터를 제공하는 공급자와 우리에게 오는 클라이언트 모두에서 이러한 문제를 봅니다. 그리고 다른 컨설팅 관리 회사에서 우리를 찾아온 고객으로부터도 마찬가지입니다. 즉, 비극의 규모는 실제로 매우 크다.

오늘 제가 이야기할 내용은 문자 그대로 세 가지입니다.

1. 사용자 권한과 포드 권한. 사용자 권한과 포드 권한은 동일하지 않습니다.
2. 클러스터에 대한 정보를 수집합니다. 이 클러스터에 특별한 권한이 없어도 클러스터에서 필요한 모든 정보를 수집할 수 있음을 보여 드리겠습니다.
3. 클러스터에 대한 DoS 공격. 정보를 수집할 수 없다면 어떤 경우에도 클러스터를 구축할 수 있습니다. 클러스터 제어 요소에 대한 DoS 공격에 대해 이야기하겠습니다.

제가 언급할 또 다른 일반적인 사항은 제가 이 모든 것을 테스트한 것입니다. 이 테스트에서는 모든 것이 작동한다고 확실히 말할 수 있습니다.

우리는 Kubespray를 사용하여 Kubernetes 클러스터 설치를 기본으로 삼습니다. 모르는 사람이 있다면 이는 실제로 Ansible의 역할 집합입니다. 우리는 그것을 업무에 지속적으로 사용합니다. 좋은 점은 어디에서나 굴릴 수 있다는 것입니다. 철 조각이나 구름 어딘가에 굴릴 수 있습니다. 하나의 설치 방법은 원칙적으로 모든 것에 적용됩니다.

이 클러스터에는 Kubernetes v1.14.5가 있습니다. 우리가 고려할 전체 큐브 클러스터는 네임스페이스로 나누어지고, 각 네임스페이스는 별도의 팀에 속하며, 이 팀의 구성원은 각 네임스페이스에 액세스할 수 있습니다. 다른 네임스페이스로는 이동할 수 없으며 자신의 네임스페이스로만 이동할 수 있습니다. 그러나 전체 클러스터에 대한 권한을 가진 특정 관리자 계정이 있습니다.

가장 먼저 할 일은 클러스터에 대한 관리자 권한을 얻는 것이라고 약속했습니다. Kubernetes 클러스터를 중단할 특별히 준비된 포드가 필요합니다. 우리가 해야 할 일은 이를 Kubernetes 클러스터에 적용하는 것뿐입니다.

kubectl apply -f pod.yaml

이 포드는 Kubernetes 클러스터의 마스터 중 하나에 도착합니다. 그 후에 클러스터는 admin.conf라는 파일을 우리에게 반환할 것입니다. Cube에서 이 파일은 모든 관리자 인증서를 저장함과 동시에 클러스터 API를 구성합니다. 이것이 바로 Kubernetes 클러스터의 98%에 대한 관리자 액세스 권한을 얻는 것이 얼마나 쉬운지입니다.

반복합니다. 이 포드는 자신의 제안을 하나의 작은 네임스페이스에 배포할 수 있는 액세스 권한이 있는 클러스터의 한 개발자가 만들었으며 모두 RBAC에 의해 고정되어 있습니다. 그에게는 권리가 없었습니다. 그럼에도 불구하고 인증서가 반환되었습니다.

그리고 이제 특별히 준비된 포드에 대해 설명합니다. 우리는 모든 이미지에서 이를 실행합니다. debian:jessie를 예로 들어보겠습니다.

우리는 이것을 가지고 있습니다:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

관용이란 무엇입니까? Kubernetes 클러스터의 마스터는 일반적으로 taint라는 항목으로 표시됩니다. 그리고 이 "감염"의 본질은 Pod를 마스터 노드에 할당할 수 없다는 것입니다. 그러나 어느 누구도 꼬투리에서 "감염"에 내성이 있음을 나타내려고 하지 않습니다. Toleration 섹션에서는 일부 노드에 NoSchedule이 있으면 우리 노드가 그러한 감염에 대해 내성이 있으며 문제가 없다고 말합니다.

또한 우리의 하위는 관대할 뿐만 아니라, 특히 마스터를 목표로 삼고 싶어한다고 말합니다. 주인은 우리에게 필요한 가장 맛있는 것, 즉 모든 인증서를 가지고 있기 때문입니다. 따라서 우리는 nodeSelector라고 부릅니다. 그리고 마스터에 대한 표준 레이블이 있습니다. 이를 통해 클러스터의 모든 노드 중에서 정확히 마스터인 노드를 선택할 수 있습니다.

이 두 섹션을 통해 그는 확실히 마스터에게 올 것입니다. 그리고 그는 그곳에서 살도록 허락될 것입니다.

그러나 단지 주인에게 오는 것만으로는 충분하지 않습니다. 이것은 우리에게 아무것도 주지 않을 것입니다. 다음에는 다음 두 가지가 있습니다.

hostNetwork: true 
hostPID: true 

우리가 시작하는 포드가 커널 네임스페이스, 네트워크 네임스페이스 및 PID 네임스페이스에 위치하도록 지정합니다. 포드가 마스터에서 실행되면 이 노드의 모든 실제 라이브 인터페이스를 볼 수 있고, 모든 트래픽을 듣고, 모든 프로세스의 PID를 볼 수 있습니다.

그렇다면 그것은 작은 일의 문제이다. etcd를 가지고 원하는 것을 읽으십시오.

가장 흥미로운 점은 기본적으로 존재하는 Kubernetes 기능입니다.

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

그리고 그 핵심은 이 클러스터에 대한 권한이 없더라도 우리가 시작하는 포드에서 호스트 경로 유형의 볼륨을 생성하고 싶다고 말할 수 있다는 것입니다. 이는 우리가 시작할 호스트의 경로를 가져와서 볼륨으로 가져오는 것을 의미합니다. 그런 다음 이름을 호스트라고 부릅니다. 이 전체 호스트 경로를 포드 내부에 마운트합니다. 이 예에서는 /host 디렉터리로 이동합니다.

다시 반복하겠습니다. 우리는 포드에게 마스터로 와서 거기에서 호스트 네트워크와 호스트PID를 가져오고 이 포드 안에 마스터의 전체 루트를 마운트하라고 지시했습니다.

데비안에서는 bash가 실행되고 있고 이 bash는 루트에서 실행된다는 것을 이해하실 것입니다. 즉, Kubernetes 클러스터에 대한 권한 없이 마스터에서 루트를 방금 받았습니다.

그런 다음 전체 작업은 하위 디렉터리 /host /etc/kubernetes/pki로 이동하는 것입니다. 제가 착각한 것이 아니라면 그곳에서 클러스터의 모든 마스터 인증서를 선택하여 그에 따라 클러스터 관리자가 됩니다.

이런 식으로 살펴보면 사용자가 어떤 권한을 가지고 있는지에 관계없이 포드에서 가장 위험한 권한 중 일부는 다음과 같습니다.

클러스터의 일부 네임스페이스에서 포드를 실행할 수 있는 권한이 있는 경우 이 포드에는 기본적으로 이러한 권한이 있습니다. 권한 있는 포드를 실행할 수 있으며 이는 일반적으로 모든 권한을 가지며 실제로 노드의 루트입니다.

내가 가장 좋아하는 것은 루트 사용자입니다. 그리고 Kubernetes에는 Run As Non-Root 옵션이 있습니다. 이것은 해커로부터의 일종의 보호입니다. '몰다비아 바이러스'가 무엇인지 아시나요? 갑자기 해커가 되어 내 Kubernetes 클러스터에 오면 불쌍한 관리자인 우리는 다음과 같이 질문합니다. “내 클러스터를 해킹할 포드를 루트가 아닌 사용자로 실행하도록 지정하세요. 그렇지 않으면 루트로 Pod에서 프로세스를 실행하게 되어 해킹하기가 매우 쉽습니다. 자신으로부터 자신을 보호해주세요."

제 생각에는 호스트 경로 볼륨이 Kubernetes 클러스터에서 원하는 결과를 얻는 가장 빠른 방법입니다.

하지만 이 모든 것을 어떻게 해야 할까요?

Kubernetes를 접하는 일반 관리자는 다음과 같은 생각을 해야 합니다. “예, Kubernetes는 작동하지 않습니다. 거기에 구멍이 있습니다. 그리고 큐브 전체가 헛소리야.” 사실 문서 같은게 있는데, 거기 보시면 섹션이 있어요. 포드 보안 정책.

이는 Pod 설명에서 보안 측면을 구체적으로 제어하는 ​​yaml 개체입니다. Kubernetes 클러스터에서 생성할 수 있습니다. 즉, 실제로 시작 시 포드에 있는 모든 호스트 네트워크, 호스트 PID, 특정 볼륨 유형을 사용할 수 있는 권한을 제어합니다. Pod 보안 정책을 사용하면 이 모든 것을 설명할 수 있습니다.

포드 보안 정책에서 가장 흥미로운 점은 Kubernetes 클러스터에서 모든 PSP 설치 프로그램이 어떤 방식으로든 설명되지 않고 기본적으로 단순히 비활성화되어 있다는 것입니다. 포드 보안 정책은 승인 플러그인을 사용하여 활성화됩니다.

좋습니다. 클러스터에 포드 보안 정책을 배포해 보겠습니다. 네임스페이스에 관리자만 액세스할 수 있는 일부 서비스 포드가 있다고 가정해 보겠습니다. 다른 모든 경우에는 Pod에 제한된 권한이 있다고 가정해 보겠습니다. 대부분의 개발자는 클러스터에서 권한 있는 Pod를 실행할 필요가 없기 때문입니다.

그리고 우리에게는 모든 것이 괜찮은 것 같습니다. 그리고 우리 Kubernetes 클러스터는 XNUMX분 안에 해킹될 수 없습니다.

문제가 있습니다. Kubernetes 클러스터가 있는 경우 클러스터에 모니터링이 설치될 가능성이 높습니다. 클러스터에 모니터링 기능이 있으면 Prometheus라고 불릴 것이라고 예측하기도 합니다.

제가 말씀드리고자 하는 내용은 Prometheus 운영자와 순수한 형태로 제공되는 Prometheus 모두에 유효합니다. 문제는 관리자를 클러스터에 그렇게 빨리 포함시킬 수 없다면 더 많은 것을 살펴봐야 한다는 것입니다. 그리고 여러분의 모니터링을 통해 검색할 수 있습니다.

아마도 모두가 Habré에서 동일한 기사를 읽고 모니터링은 모니터링 네임스페이스에 위치할 것입니다. Helm 차트는 모든 사람에게 거의 동일하게 호출됩니다. 나는 helm install stable/prometheus를 수행하면 대략 동일한 이름을 얻게 될 것이라고 추측합니다. 그리고 아마도 클러스터의 DNS 이름을 추측할 필요조차 없을 것입니다. 표준이기 때문이죠.

다음으로 특정 포드를 실행할 수 있는 특정 개발 NS가 있습니다. 그리고 이 포드에서 다음과 같은 작업을 수행하는 것은 매우 쉽습니다.

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics는 Kubernetes API 자체에서 지표를 수집하는 Prometheus 내보내기 중 하나입니다. 거기에는 클러스터에서 실행 중인 데이터가 무엇인지, 클러스터에 어떤 문제가 있는지 등 많은 데이터가 있습니다.

간단한 예를 들면 다음과 같습니다.

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

권한이 없는 Pod에서 간단한 컬 요청을 하면 다음 정보를 얻을 수 있습니다. 실행 중인 Kubernetes 버전을 모르는 경우 쉽게 알려줄 것입니다.

가장 흥미로운 점은 kube-state-metrics에 액세스하는 것 외에도 Prometheus 자체에 직접 쉽게 액세스할 수 있다는 것입니다. 거기에서 측정항목을 수집할 수 있습니다. 거기에서 측정항목을 작성할 수도 있습니다. 이론적으로도 Prometheus의 클러스터에서 이러한 쿼리를 구축하면 간단히 꺼질 수 있습니다. 그리고 모니터링이 클러스터에서 완전히 작동하지 않습니다.

그리고 여기서 외부 모니터링이 귀하의 모니터링을 모니터링하는지 여부에 대한 의문이 제기됩니다. 방금 아무런 결과 없이 Kubernetes 클러스터에서 작업할 수 있는 기회를 얻었습니다. 더 이상 모니터링이 없기 때문에 내가 그곳에서 활동하고 있다는 사실조차 모를 것입니다.

PSP와 마찬가지로 Kubernetes, Prometheus와 같은 멋진 기술이 모두 작동하지 않고 허점으로 가득 차 있다는 것이 문제인 것 같습니다. 설마.

그런게 있어요 - 네트워크 정책.

일반 관리자라면 이것이 단지 또 다른 yaml이며 클러스터에 이미 많은 yaml이 있다는 것을 네트워크 정책에 대해 알고 있을 것입니다. 그리고 일부 네트워크 정책은 꼭 필요하지 않습니다. 그리고 네트워크 정책이 Kubernetes의 yaml 방화벽이라는 것을 읽어보더라도 이를 통해 네임스페이스 간, 포드 간 액세스 권한을 제한할 수 있습니다. 그러면 Kubernetes의 yaml 형식 방화벽이 다음 추상화를 기반으로 한다고 확실히 결정하셨을 것입니다. ... 아니, 아니. 이것은 확실히 필요하지 않습니다.

보안 전문가에게 Kubernetes를 사용하면 매우 쉽고 간단하며 매우 세분화된 방화벽을 구축할 수 있다는 사실을 말하지 않았더라도 마찬가지입니다. 그들이 아직 이것을 모르고 당신을 괴롭히지 않는다면: "글쎄, 주세요, 주세요..." 그러면 어쨌든 클러스터에서 가져올 수 있는 일부 서비스 위치에 대한 액세스를 차단하는 네트워크 정책이 필요합니다. 어떤 승인도 없이.

제가 제시한 예에서와 같이 권한 없이도 Kubernetes 클러스터의 모든 네임스페이스에서 kube 상태 메트릭을 가져올 수 있습니다. 네트워크 정책은 다른 모든 네임스페이스에서 모니터링 네임스페이스에 대한 액세스를 차단했습니다. 즉, 액세스가 불가능하고 문제가 없습니다. 존재하는 모든 차트에는 표준 Prometheus와 Operator에 있는 Prometheus 모두 단순히 네트워크 정책을 활성화하기 위한 helm 값의 옵션만 있습니다. 전원을 켜기만 하면 작동합니다.

여기에는 정말 한 가지 문제가 있습니다. 일반적인 수염 관리자라면 네트워크 정책이 필요하지 않다고 판단했을 가능성이 높습니다. 그리고 Habr과 같은 리소스에 대한 모든 종류의 기사를 읽은 후 특히 호스트 게이트웨이 모드의 경우 플란넬이 선택할 수 있는 최선의 방법이라고 결정했습니다.

무엇을해야 하는가?

Kubernetes 클러스터에 있는 네트워크 솔루션을 재배포하고 더 기능적인 솔루션으로 교체해 볼 수 있습니다. 예를 들어 동일한 Calico의 경우. 하지만 Kubernetes 작업 클러스터에서 네트워크 솔루션을 변경하는 작업은 매우 간단하지 않다는 점을 바로 말씀드리고 싶습니다. 나는 이 문제를 두 번 풀었지만(두 번 모두 이론적으로는) Slurms에서 그 방법을 보여주기도 했습니다. 학생들을 위해 Kubernetes 클러스터에서 네트워크 솔루션을 변경하는 방법을 보여주었습니다. 원칙적으로 프로덕션 클러스터에 가동 중지 시간이 없는지 확인할 수 있습니다. 하지만 아마도 성공하지 못할 것입니다.

그리고 문제는 실제로 매우 간단하게 해결됩니다. 클러스터에 인증서가 있으며 인증서가 XNUMX년 후에 만료된다는 것을 알고 있습니다. 글쎄, 일반적으로 클러스터에 인증서가 있는 일반적인 솔루션입니다. 왜 걱정합니까? 근처에 새 클러스터를 만들고 이전 클러스터를 썩게 두고 모든 것을 재배포할 것입니다. 사실, 그것이 썩으면 하루 동안 앉아 있어야 하지만 여기에 새로운 클러스터가 있습니다.

새 클러스터를 키울 때 동시에 플란넬 대신 옥양목을 삽입하십시오.

인증서가 XNUMX년 동안 발급되었고 클러스터를 재배포하지 않을 경우 어떻게 해야 합니까? Kube-RBAC-Proxy와 같은 것이 있습니다. 이는 매우 멋진 개발입니다. Kubernetes 클러스터의 모든 포드에 사이드카 컨테이너로 포함할 수 있습니다. 그리고 실제로 Kubernetes 자체의 RBAC를 통해 이 Pod에 권한을 추가합니다.

한 가지 문제가 있습니다. 이전에는 이 Kube-RBAC-Proxy 솔루션이 운영자의 Prometheus에 내장되었습니다. 그러나 그는 사라졌습니다. 이제 최신 버전은 네트워크 정책이 있고 이를 사용하여 종료한다는 사실에 의존합니다. 그러므로 우리는 차트를 조금 다시 작성해야 할 것입니다. 사실 가보면 이 저장소, 이것을 사이드카로 사용하는 방법에 대한 예가 있으며 차트는 최소한으로 다시 작성해야 합니다.

작은 문제가 하나 더 있습니다. Prometheus는 누구에게나 측정항목을 전달하는 유일한 업체가 아닙니다. 모든 Kubernetes 클러스터 구성 요소는 자체 측정항목을 반환할 수도 있습니다.

하지만 이미 말했듯이 클러스터에 액세스하여 정보를 수집할 수 없다면 최소한 어느 정도 해를 끼칠 수는 있습니다.

따라서 Kubernetes 클러스터가 어떻게 망가질 수 있는지 두 가지 방법을 빠르게 보여 드리겠습니다.

내가 이것을 말하면 당신은 웃을 것입니다. 이것은 두 가지 실제 사례입니다.

방법 XNUMX. 자원 고갈.

또 다른 특별한 포드를 출시해 보겠습니다. 이런 부분이 있을 겁니다.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

아시다시피 요청은 요청이 있는 특정 Pod에 대해 호스트에 예약된 CPU 및 메모리의 양입니다. Kubernetes 클러스터에 XNUMX코어 호스트가 있고 XNUMX개의 CPU Pod가 요청과 함께 도착하는 경우 요청이 있는 Pod가 더 이상 이 호스트에 올 수 없음을 의미합니다.

이러한 포드를 실행하면 다음 명령을 실행합니다.

$ kubectl scale special-pod --replicas=...

그러면 다른 누구도 Kubernetes 클러스터에 배포할 수 없습니다. 모든 노드에 요청이 부족하기 때문입니다. 따라서 귀하의 Kubernetes 클러스터를 중지하겠습니다. 저녁에 이 작업을 수행하면 꽤 오랜 시간 동안 배포를 중단할 수 있습니다.

Kubernetes 문서를 다시 보면 Limit Range라는 항목이 표시됩니다. 클러스터 개체에 대한 리소스를 설정합니다. yaml에 Limit Range 객체를 작성하고 이를 특정 네임스페이스에 적용할 수 있습니다. 그런 다음 이 네임스페이스에는 포드에 대한 기본, 최대 및 최소 리소스가 있다고 말할 수 있습니다.

이러한 기능의 도움으로 우리는 팀의 특정 제품 네임스페이스에 있는 사용자가 포드에 있는 모든 종류의 불쾌한 항목을 표시하는 능력을 제한할 수 있습니다. 하지만 불행하게도 사용자에게 두 개 이상의 CPU에 대한 요청으로 Pod를 시작할 수 없다고 말해도 훌륭한 scale 명령이 있거나 대시보드를 통해 규모를 조정할 수 있습니다.

그리고 이것이 두 번째 방법이 나오는 곳입니다. 우리는 11개의 포드를 출시합니다. 그것은 111억입니다. 그런 숫자를 생각해 낸 것이 아니라 직접 봤기 때문입니다.

실화. 저녁 늦게 나는 사무실을 떠나려고 했다. 저는 한 무리의 개발자들이 구석에 앉아 미친 듯이 노트북으로 무언가를 하고 있는 것을 봅니다. 나는 남자들에게 다가가 "무슨 일이 있었나요? "라고 묻습니다.

조금 더 이른 저녁 XNUMX시쯤, 개발자 중 한 명이 집에 갈 준비를 하고 있었습니다. 그리고 저는 “이제 애플리케이션을 하나로 축소하겠습니다.”라고 결정했습니다. 하나를 눌렀는데 인터넷이 조금 느려졌습니다. 그는 하나를 다시 누르고, 하나를 누르고 Enter를 클릭했습니다. 나는 내가 할 수 있는 모든 것을 찔렀다. 그런 다음 인터넷이 활성화되었고 모든 것이 이 숫자로 축소되기 시작했습니다.

사실, 이 이야기는 Kubernetes에서 발생하지 않았으며 당시에는 Nomad였습니다. Nomad의 지속적인 확장 시도를 막으려는 우리의 시도가 한 시간 후에 Nomad는 확장을 중단하지 않고 다른 작업을 수행하지 않겠다고 대답했다는 사실로 끝났습니다. "피곤해요, 나 갈게요." 그리고 그는 몸을 웅크렸습니다.

당연히 Kubernetes에서도 동일한 작업을 시도했습니다. Kubernetes는 1억 개의 포드가 만족스럽지 않다고 말했습니다. “할 수 없습니다. 내부 마우스 가드를 초과합니다." 하지만 000개의 포드는 가능합니다.

XNUMX억에 대응하여 큐브는 스스로 물러나지 않았습니다. 그는 실제로 스케일링을 시작했습니다. 프로세스가 진행될수록 새 포드를 만드는 데 더 많은 시간이 걸렸습니다. 그러나 여전히 과정은 계속되었습니다. 유일한 문제는 내 네임스페이스에서 포드를 무제한으로 시작할 수 있다면 요청과 제한 없이도 일부 작업이 포함된 너무 많은 포드를 시작할 수 있으며 이러한 작업의 도움으로 노드가 메모리, CPU에 추가되기 시작한다는 것입니다. 너무 많은 포드를 시작하면 해당 포드의 정보가 스토리지, 즉 etcd로 이동해야 합니다. 그리고 너무 많은 정보가 도착하면 스토리지가 너무 느리게 반환되기 시작하고 Kubernetes가 둔해지기 시작합니다.

그리고 또 하나의 문제... 아시다시피 Kubernetes 제어 요소는 하나의 핵심 요소가 아니라 여러 구성 요소입니다. 특히 컨트롤러 관리자, 스케줄러 등이 있습니다. 이 모든 사람들은 동시에 불필요하고 어리석은 작업을 시작하며 시간이 지남에 따라 점점 더 많은 시간이 걸리기 시작할 것입니다. 컨트롤러 관리자가 새 포드를 생성합니다. 스케줄러는 이를 위한 새 노드를 찾으려고 시도합니다. 곧 클러스터의 새 노드가 부족해질 가능성이 높습니다. Kubernetes 클러스터는 점점 더 느리게 작동하기 시작합니다.

그러나 나는 더 나아가기로 결정했습니다. 아시다시피 Kubernetes에는 서비스라는 것이 있습니다. 기본적으로 클러스터에서는 서비스가 IP 테이블을 사용하여 작동할 가능성이 높습니다.

예를 들어 XNUMX억 개의 포드를 실행한 다음 스크립트를 사용하여 Kubernetis가 새 서비스를 생성하도록 하는 경우:

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

클러스터의 모든 노드에서 점점 더 많은 새로운 iptables 규칙이 거의 동시에 생성됩니다. 또한 각 서비스에 대해 XNUMX억 개의 iptables 규칙이 생성됩니다.

나는이 모든 것을 수천에서 최대 XNUMX까지 확인했습니다. 그리고 문제는 이미 이 임계값에서 노드에 SSH를 수행하는 것이 상당히 문제가 있다는 것입니다. 너무 많은 체인을 통과하는 패킷은 기분이 좋지 않기 시작합니다.

이 문제도 Kubernetes의 도움으로 모두 해결되었습니다. 이러한 리소스 할당량 개체가 있습니다. 클러스터의 네임스페이스에 사용 가능한 리소스 및 개체 수를 설정합니다. Kubernetes 클러스터의 각 네임스페이스에 yaml 객체를 생성할 수 있습니다. 이 객체를 사용하면 이 네임스페이스에 특정 개수의 요청과 제한이 할당되어 있다고 말할 수 있으며, 이 네임스페이스에서는 10개의 서비스와 10개의 포드를 생성할 수 있다고 말할 수 있습니다. 그리고 한 명의 개발자는 적어도 저녁에는 목이 막힐 수 있습니다. Kubernetes는 그에게 "리소스가 할당량을 초과하기 때문에 포드를 해당 양으로 확장할 수 없습니다."라고 말할 것입니다. 그게 다야, 문제가 해결되었습니다. 여기 문서.

이와 관련하여 한 가지 문제점이 발생합니다. Kubernetes에서 네임스페이스를 생성하는 것이 얼마나 어려워지고 있는지 느끼실 것입니다. 그것을 만들려면 많은 것을 고려해야 합니다.

리소스 할당량 + 제한 범위 + RBAC
• 네임스페이스 생성
• 내부에 제한 범위를 만듭니다.
• 내부 리소스 할당량 생성
• CI용 서비스 계정 생성
• CI 및 사용자에 대한 역할 바인딩 생성
• 선택적으로 필요한 서비스 포드 실행

그러므로 저는 이 기회를 빌어 제가 발전한 내용을 공유하고 싶습니다. SDK 오퍼레이터라는 것이 있습니다. 이는 Kubernetes 클러스터가 연산자를 작성하는 방법입니다. Ansible을 사용하여 명령문을 작성할 수 있습니다.

처음에는 Ansible로 작성했다가 SDK Operator가 있는 것을 보고 Ansible 역할을 Operator로 다시 작성했습니다. 이 문을 사용하면 Kubernetes 클러스터에 명령이라는 개체를 생성할 수 있습니다. 명령 내에서 yaml에서 이 명령에 대한 환경을 설명할 수 있습니다. 그리고 팀 환경 내에서 우리가 너무 많은 리소스를 할당하고 있음을 설명할 수 있습니다.

조금 이 모든 복잡한 과정을 더 쉽게 만들어줍니다.

그리고 결론적으로. 이 모든 것을 어떻게 해야 할까요?
첫 번째. 포드 보안 정책이 좋습니다. 그리고 현재까지 Kubernetes 설치 프로그램 중 누구도 이를 사용하지 않는다는 사실에도 불구하고 클러스터에서는 여전히 이를 사용해야 합니다.

네트워크 정책은 또 다른 불필요한 기능이 아닙니다. 이것이 클러스터에 실제로 필요한 것입니다.

LimitRange/ResourceQuota - 이제 사용할 시간입니다. 우리는 오래 전부터 이것을 사용하기 시작했고 오랫동안 모두가 그것을 사용하고 있다고 확신했습니다. 이것은 드문 것으로 밝혀졌습니다.

보고서에서 언급한 것 외에도 클러스터를 공격할 수 있는 문서화되지 않은 기능이 있습니다. 최근 출시됨 Kubernetes 취약점에 대한 광범위한 분석.

어떤 것들은 너무 슬프고 상처를 줍니다. 예를 들어, 특정 조건에서 Kubernetes 클러스터의 큐블렛은 warlocks 디렉터리의 콘텐츠를 권한 없는 사용자에게 제공할 수 있습니다.

여기에 내가 말한 모든 것을 재현하는 방법에 대한 지침이 있습니다. ResourceQuota 및 Pod 보안 정책의 프로덕션 예시가 포함된 파일이 있습니다. 그리고 이 모든 것을 만질 수 있습니다.

고마워요.

출처 : habr.com