Corrigindo falhas no cluster Kubernetes. Relatório e transcrição da DevOpsConf

Pavel Selivanov, arquiteto de soluções Southbridge e professor de Slurm, fez uma apresentação na DevOpsConf 2019. Esta palestra faz parte de um dos tópicos do curso aprofundado sobre Kubernetes “Slurm Mega”.

Slurm Basic: uma introdução ao Kubernetes acontece em Moscou de 18 a 20 de novembro.
Slurm Mega: olhando por baixo do capô do Kubernetes — Moscou, 22 a 24 de novembro.
Slurm Online: ambos os cursos Kubernetes sempre disponível.

Abaixo do corte está uma transcrição do relatório.

Boa tarde, colegas e aqueles que simpatizam com eles. Hoje vou falar sobre segurança.

Vejo que há muitos seguranças no corredor hoje. Peço desculpas antecipadamente se uso termos do mundo da segurança que não são exatamente como são habituais para você.

Acontece que há cerca de seis meses me deparei com um cluster público do Kubernetes. Público significa que existe um enésimo número de namespaces; nesses namespaces existem usuários isolados em seu namespace. Todos esses usuários pertencem a empresas diferentes. Bem, presumiu-se que este cluster deveria ser usado como um CDN. Ou seja, eles te dão um cluster, te dão um usuário lá, você vai lá no seu namespace, implanta suas frentes.

Minha empresa anterior tentou vender esse serviço. E me pediram para cutucar o cluster para ver se essa solução era adequada ou não.

Eu vim para este cluster. Recebi direitos limitados e espaço para nome limitado. Os caras de lá entenderam o que era segurança. Eles leram sobre controle de acesso baseado em função (RBAC) no Kubernetes - e distorceram-no para que eu não pudesse iniciar pods separadamente das implantações. Não me lembro do problema que estava tentando resolver lançando um pod sem implantação, mas eu realmente queria lançar apenas um pod. Para dar sorte, decidi ver quais direitos tenho no cluster, o que posso fazer, o que não posso fazer e o que eles estragaram lá. Ao mesmo tempo, direi o que eles configuraram incorretamente no RBAC.

Acontece que em dois minutos recebi um administrador do cluster deles, olhei todos os namespaces vizinhos, vi ali as frentes de produção de empresas que já haviam adquirido o serviço e implantado. Eu mal conseguia me impedir de ir até a frente de alguém e colocar algum palavrão na página principal.

Vou lhe contar com exemplos como fiz isso e como me proteger disso.

Mas primeiro, deixe-me apresentar-me. Meu nome é Pavel Selivanov. Sou arquiteto em Southbridge. Eu entendo Kubernetes, DevOps e todo tipo de coisas sofisticadas. Os engenheiros de Southbridge e eu estamos construindo tudo isso e eu estou prestando consultoria.

Além de nossas atividades principais, lançamos recentemente projetos chamados Slurms. Estamos tentando levar um pouco nossa capacidade de trabalhar com Kubernetes para as massas, para ensinar outras pessoas a trabalhar também com K8s.

Sobre o que vou falar hoje? O tema do relatório é óbvio - sobre a segurança do cluster Kubernetes. Mas quero dizer desde já que este assunto é muito amplo - e por isso quero esclarecer imediatamente sobre o que definitivamente não irei falar. Não vou falar de termos banais que já foram usados ​​centenas de vezes na Internet. Todos os tipos de RBAC e certificados.

Falarei sobre o que preocupa a mim e a meus colegas em relação à segurança em um cluster Kubernetes. Vemos esses problemas tanto entre os provedores que fornecem clusters Kubernetes quanto entre os clientes que nos procuram. E até mesmo de clientes que nos procuram vindos de outras empresas de consultoria administrativa. Ou seja, a escala da tragédia é realmente muito grande.

Existem literalmente três pontos sobre os quais falarei hoje:

1. Direitos do usuário versus direitos do pod. Os direitos do usuário e os direitos do pod não são a mesma coisa.
2. Coletando informações sobre o cluster. Mostrarei que você pode coletar todas as informações necessárias de um cluster sem ter direitos especiais nesse cluster.
3. Ataque DoS no cluster. Se não conseguirmos coletar informações, poderemos colocar um cluster de qualquer maneira. Falarei sobre ataques DoS em elementos de controle de cluster.

Outra coisa geral que mencionarei é onde testei tudo isso, onde posso dizer com certeza que tudo funciona.

Tomamos como base a instalação de um cluster Kubernetes utilizando Kubespray. Se alguém não sabe, este é na verdade um conjunto de funções do Ansible. Nós o usamos constantemente em nosso trabalho. O bom é que você pode enrolá-lo em qualquer lugar - você pode enrolá-lo em pedaços de ferro ou em uma nuvem em algum lugar. Um método de instalação funciona, em princípio, para tudo.

Neste cluster terei o Kubernetes v1.14.5. Todo o cluster Cube, que consideraremos, é dividido em namespaces, cada namespace pertence a uma equipe separada e os membros dessa equipe têm acesso a cada namespace. Eles não podem ir para namespaces diferentes, apenas para o seu próprio. Mas existe uma determinada conta de administrador que tem direitos para todo o cluster.

Prometi que a primeira coisa que faremos é obter direitos de administrador para o cluster. Precisamos de um pod especialmente preparado que quebre o cluster Kubernetes. Tudo o que precisamos fazer é aplicá-lo ao cluster Kubernetes.

kubectl apply -f pod.yaml

Este pod chegará a um dos mestres do cluster Kubernetes. E depois disso o cluster retornará para nós um arquivo chamado admin.conf. No Cube, este arquivo armazena todos os certificados de administrador e ao mesmo tempo configura a API do cluster. Acho que é tão fácil obter acesso de administrador a 98% dos clusters Kubernetes.

Repito, este pod foi feito por um desenvolvedor em seu cluster que tem acesso para implantar suas propostas em um pequeno namespace, tudo é limitado pelo RBAC. Ele não tinha direitos. Mesmo assim, o certificado foi devolvido.

E agora sobre um pod especialmente preparado. Executamos em qualquer imagem. Vamos pegar debian:jessie como exemplo.

Temos esta coisa:

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

O que é tolerância? Os mestres em um cluster Kubernetes geralmente são marcados com algo chamado taint. E a essência dessa “infecção” é que ela diz que os pods não podem ser atribuídos a nós mestres. Mas ninguém se preocupa em indicar em nenhum casulo que ele é tolerante à “infecção”. A seção Tolerância apenas diz que se algum nó tiver NoSchedule, então nosso nó é tolerante a tal infecção - e não há problemas.

Além disso, dizemos que o nosso inferior não é apenas tolerante, mas também quer atingir especificamente o mestre. Porque os mestres têm o que há de mais gostoso que precisamos - todos os certificados. Portanto, dizemos nodeSelector - e temos um rótulo padrão nos mestres, que permite selecionar de todos os nós do cluster exatamente aqueles nós que são mestres.

Com essas duas seções ele definitivamente chegará ao mestre. E ele terá permissão para morar lá.

Mas apenas ir ao mestre não é suficiente para nós. Isso não nos dará nada. Então, a seguir, temos essas duas coisas:

hostNetwork: true 
hostPID: true 

Especificamos que nosso pod, que lançamos, residirá no namespace do kernel, no namespace da rede e no namespace PID. Assim que o pod for iniciado no master, ele será capaz de ver todas as interfaces reais e ativas deste nó, ouvir todo o tráfego e ver o PID de todos os processos.

Então é uma questão de pequenas coisas. Pegue o etcd e leia o que quiser.

O mais interessante é esse recurso do Kubernetes, que está presente lá por padrão.

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

E sua essência é que podemos dizer no pod que lançamos, mesmo sem direitos para este cluster, que queremos criar um volume do tipo hostPath. Isso significa seguir o caminho do host no qual iremos iniciar - e considerá-lo como volume. E então chamamos de nome: host. Montamos todo esse hostPath dentro do pod. Neste exemplo, para o diretório /host.

Vou repetir novamente. Dissemos ao pod para ir até o master, obter o hostNetwork e o hostPID lá - e montar toda a raiz do master dentro deste pod.

Você entende que no Debian temos o bash rodando, e esse bash roda no root. Ou seja, acabamos de receber root no master, sem ter nenhum direito no cluster Kubernetes.

Então toda a tarefa é ir para o subdiretório /host /etc/kubernetes/pki, se não me engano, pegar todos os certificados mestres do cluster lá e, consequentemente, tornar-se o administrador do cluster.

Se você olhar desta forma, estes são alguns dos direitos mais perigosos em pods - independentemente dos direitos do usuário:

Se eu tiver direitos para executar um pod em algum namespace do cluster, esse pod terá esses direitos por padrão. Posso executar pods privilegiados, e geralmente todos têm direitos, praticamente root no nó.

Meu favorito é o usuário Root. E o Kubernetes tem essa opção Executar como não root. Este é um tipo de proteção contra um hacker. Você sabe o que é o “vírus da Moldávia”? Se de repente você for um hacker e vier ao meu cluster Kubernetes, então nós, pobres administradores, perguntamos: “Por favor, indique em seus pods com os quais você irá hackear meu cluster, execute como não-root. Caso contrário, acontecerá que você execute o processo em seu pod como root e será muito fácil para você me hackear. Por favor, proteja-se de si mesmo."

O volume do caminho do host é, na minha opinião, a maneira mais rápida de obter o resultado desejado de um cluster Kubernetes.

Mas o que fazer com tudo isso?

O pensamento que deve ocorrer a qualquer administrador normal que encontre o Kubernetes é: “Sim, eu disse a você, o Kubernetes não funciona. Existem buracos nele. E todo o Cubo é uma besteira.” Na verdade, existe documentação, e se você olhar lá, há uma seção Política de segurança de pod.

Este é um objeto yaml - podemos criá-lo no cluster Kubernetes - que controla aspectos de segurança especificamente na descrição dos pods. Ou seja, ele controla os direitos de uso de qualquer hostNetwork, hostPID, determinados tipos de volume que estão nos pods na inicialização. Com a ajuda da Política de Segurança do Pod, tudo isso pode ser descrito.

O mais interessante sobre a Política de Segurança do Pod é que no cluster Kubernetes, todos os instaladores do PSP não são apenas descritos de forma alguma, eles são simplesmente desabilitados por padrão. A política de segurança do pod é habilitada usando o plugin de admissão.

Ok, vamos implantar a política de segurança de pod no cluster, digamos que temos alguns pods de serviço no namespace, aos quais apenas administradores têm acesso. Digamos que, em todos os outros casos, os pods tenham direitos limitados. Porque provavelmente os desenvolvedores não precisam executar pods privilegiados em seu cluster.

E tudo parece estar bem conosco. E nosso cluster Kubernetes não pode ser hackeado em dois minutos.

Há um problema. Provavelmente, se você tiver um cluster Kubernetes, o monitoramento estará instalado em seu cluster. Eu chegaria ao ponto de prever que se o seu cluster tiver monitoramento, ele se chamará Prometheus.

O que estou prestes a dizer será válido tanto para o operador Prometheus quanto para o Prometheus entregue em sua forma pura. A questão é que, se não consigo colocar um administrador no cluster tão rapidamente, isso significa que preciso procurar mais. E posso pesquisar com a ajuda do seu monitoramento.

Provavelmente todos leram os mesmos artigos no Habré, e o monitoramento está localizado no namespace de monitoramento. O gráfico do Helm é chamado aproximadamente da mesma forma para todos. Suponho que se você helm install stable/prometheus, terminará com aproximadamente os mesmos nomes. E provavelmente nem precisarei adivinhar o nome DNS do seu cluster. Porque é padrão.

Em seguida, temos um determinado dev ns, no qual você pode executar um determinado pod. E a partir deste pod é muito fácil fazer algo assim:

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

prometheus-kube-state-metrics é um dos exportadores do Prometheus que coleta métricas da própria API Kubernetes. Há muitos dados aí, o que está rodando no seu cluster, o que é, quais problemas você tem com isso.

Como um exemplo simples:

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

Ao fazer uma solicitação curl simples de um pod sem privilégios, você pode obter as seguintes informações. Se você não sabe qual versão do Kubernetes está executando, ele lhe dirá facilmente.

E o mais interessante é que além de acessar as métricas do estado do kube, você pode acessar diretamente o próprio Prometheus com a mesma facilidade. Você pode coletar métricas a partir daí. Você pode até construir métricas a partir daí. Mesmo teoricamente, você pode criar essa consulta a partir de um cluster no Prometheus, o que simplesmente a desativará. E seu monitoramento deixará de funcionar completamente no cluster.

E aqui surge a questão se algum monitoramento externo monitora o seu monitoramento. Acabei de ter a oportunidade de operar em um cluster Kubernetes sem quaisquer consequências para mim. Você nem vai saber que estou operando lá, pois não há mais monitoramento.

Assim como no PSP, parece que o problema é que todas essas tecnologias sofisticadas – Kubernetes, Prometheus – simplesmente não funcionam e estão cheias de buracos. Na verdade.

Existe tal coisa - Política de rede.

Se você é um administrador normal, provavelmente sabe sobre a Política de Rede que este é apenas mais um yaml, do qual já existem muitos no cluster. E algumas políticas de rede definitivamente não são necessárias. E mesmo se você ler o que é Política de Rede, que é um firewall yaml do Kubernetes, permite limitar os direitos de acesso entre namespaces, entre pods, então você certamente decidiu que o firewall no formato yaml no Kubernetes é baseado nas seguintes abstrações ... Não não . Definitivamente, isso não é necessário.

Mesmo que você não tenha dito aos seus especialistas em segurança que usando o Kubernetes você pode construir um firewall muito fácil e simples, e muito granular. Se eles ainda não sabem disso e não incomodam você: “Bem, me dê, me dê...” Então, em qualquer caso, você precisa de uma Política de Rede para bloquear o acesso a alguns locais de serviço que podem ser extraídos do seu cluster sem qualquer autorização.

Como no exemplo que dei, você pode obter métricas de estado do kube de qualquer namespace no cluster Kubernetes sem ter nenhum direito para fazer isso. As políticas de rede fecharam o acesso de todos os outros namespaces ao namespace de monitoramento e pronto: sem acesso, sem problemas. Em todos os gráficos que existem, tanto no Prometheus padrão quanto no Prometheus que está na operadora, existe simplesmente uma opção nos valores do leme para simplesmente habilitar políticas de rede para eles. Você só precisa ligá-lo e eles funcionarão.

Há realmente um problema aqui. Sendo um administrador barbudo normal, você provavelmente decidiu que as políticas de rede não são necessárias. E depois de ler todos os tipos de artigos sobre recursos como Habr, você decidiu que flanela, especialmente no modo host-gateway, é a melhor coisa que você pode escolher.

O que fazer?

Você pode tentar reimplantar a solução de rede que possui em seu cluster Kubernetes e tentar substituí-la por algo mais funcional. Para o mesmo Calico, por exemplo. Mas quero dizer imediatamente que a tarefa de alterar a solução de rede em um cluster funcional do Kubernetes não é nada trivial. Resolvi duas vezes (ambas, porém, teoricamente), mas até mostramos como fazer no Slurms. Para nossos alunos, mostramos como alterar a solução de rede em um cluster Kubernetes. Em princípio, você pode tentar garantir que não haja tempo de inatividade no cluster de produção. Mas você provavelmente não terá sucesso.

E o problema é resolvido de forma muito simples. Existem certificados no cluster e você sabe que seus certificados expirarão em um ano. Bem, e geralmente uma solução normal com certificados no cluster - por que estamos preocupados, criaremos um novo cluster próximo, deixaremos o antigo apodrecer e reimplantaremos tudo. É verdade que, quando apodrecer, teremos que ficar sentados por um dia, mas aqui está um novo grupo.

Ao criar um novo cacho, insira ao mesmo tempo Calico em vez de flanela.

O que fazer se seus certificados forem emitidos há cem anos e você não for reimplantar o cluster? Existe algo como Kube-RBAC-Proxy. Este é um desenvolvimento muito interessante, pois permite incorporar-se como um contêiner secundário a qualquer pod no cluster Kubernetes. E na verdade adiciona autorização a este pod por meio do próprio RBAC do Kubernetes.

Há um problema. Anteriormente, esta solução Kube-RBAC-Proxy foi incorporada ao Prometheus da operadora. Mas então ele se foi. Agora, as versões modernas dependem do fato de você ter uma política de rede e fechá-la usando-a. E portanto teremos que reescrever um pouco o gráfico. Na verdade, se você for para este repositório, há exemplos de como usar isso como sidecars, e os gráficos terão que ser minimamente reescritos.

Há mais um pequeno problema. O Prometheus não é o único a distribuir suas métricas para qualquer pessoa. Todos os nossos componentes do cluster Kubernetes também são capazes de retornar suas próprias métricas.

Mas como eu já disse, se você não consegue acessar o cluster e coletar informações, você pode pelo menos causar algum dano.

Então, mostrarei rapidamente duas maneiras de como um cluster Kubernetes pode ser arruinado.

Você vai rir quando eu contar isso, são dois casos da vida real.

Método um. Esgotamento de recursos.

Vamos lançar mais um pod especial. Terá uma seção como esta.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

Como você sabe, solicitações é a quantidade de CPU e memória reservada no host para pods específicos com solicitações. Se tivermos um host de quatro núcleos em um cluster Kubernetes e quatro pods de CPU chegarem lá com solicitações, isso significa que nenhum outro pod com solicitações poderá chegar a esse host.

Se eu executar esse pod, executarei o comando:

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

Assim, ninguém mais poderá implantar no cluster Kubernetes. Porque todos os nós ficarão sem solicitações. E assim irei parar o seu cluster Kubernetes. Se eu fizer isso à noite, posso interromper as implantações por um bom tempo.

Se olharmos novamente a documentação do Kubernetes, veremos algo chamado Limit Range. Ele define recursos para objetos de cluster. Você pode escrever um objeto Limit Range em yaml, aplicá-lo a determinados namespaces - e então neste namespace você pode dizer que possui recursos padrão, máximo e mínimo para os pods.

Com a ajuda de tal coisa, podemos limitar os usuários em namespaces de produtos específicos das equipes na capacidade de indicar todos os tipos de coisas desagradáveis ​​em seus pods. Mas, infelizmente, mesmo se você disser ao usuário que ele não pode iniciar pods com solicitações para mais de uma CPU, existe um comando de escala maravilhoso, ou eles podem escalar por meio do painel.

E é daí que vem o método número dois. Lançamos 11 pods. São onze bilhões. Não porque eu tenha inventado esse número, mas porque eu mesmo o vi.

História real. Tarde da noite eu estava prestes a sair do escritório. Vejo um grupo de desenvolvedores sentados em um canto, fazendo algo freneticamente com seus laptops. Vou até os rapazes e pergunto: “O que aconteceu com vocês?”

Um pouco antes, por volta das nove da noite, um dos desenvolvedores se preparava para ir para casa. E decidi: “Agora reduzirei meu aplicativo para um”. Apertei um, mas a Internet ficou um pouco lenta. Ele pressionou aquele novamente, pressionou aquele e clicou em Enter. Eu cutuquei tudo que pude. Então a Internet ganhou vida - e tudo começou a diminuir para esse número.

É verdade que essa história não aconteceu no Kubernetes, naquela época era o Nomad. Terminou com o fato de que, após uma hora de nossas tentativas de impedir o Nomad de tentativas persistentes de escalar, Nomad respondeu que não iria parar de escalar e não faria mais nada. "Estou cansado, estou indo embora." E ele se enrolou.

Naturalmente, tentei fazer o mesmo no Kubernetes. Kubernetes não gostou dos onze bilhões de pods, ele disse: “Não posso. Excede os protetores bucais internos." Mas 1 de cápsulas poderiam.

Em resposta a um bilhão, o Cubo não se retirou. Ele realmente começou a escalar. Quanto mais avançava o processo, mais tempo ele levava para criar novos pods. Mas ainda assim o processo continuou. O único problema é que se eu puder iniciar pods ilimitadamente no meu namespace, mesmo sem solicitações e limites, posso iniciar tantos pods com algumas tarefas que, com a ajuda dessas tarefas, os nós começarão a se acumular na memória, na CPU. Quando eu lanço tantos pods, as informações deles devem ir para o armazenamento, ou seja, etcd. E quando muita informação chega lá, o armazenamento começa a retornar muito lentamente – e o Kubernetes começa a ficar monótono.

E mais um problema... Como você sabe, os elementos de controle do Kubernetes não são uma coisa central, mas vários componentes. Em particular, existe um gerenciador de controlador, um agendador e assim por diante. Todos esses caras começarão a fazer trabalhos desnecessários e estúpidos ao mesmo tempo, o que com o tempo começará a levar cada vez mais tempo. O gerenciador do controlador criará novos pods. O Agendador tentará encontrar um novo nó para eles. Provavelmente você ficará sem novos nós em seu cluster em breve. O cluster Kubernetes começará a funcionar cada vez mais devagar.

Mas decidi ir ainda mais longe. Como você sabe, no Kubernetes existe algo chamado serviço. Bem, por padrão em seus clusters, provavelmente o serviço funciona usando tabelas IP.

Se você executar um bilhão de pods, por exemplo, e depois usar um script para forçar o Kubernetis a criar novos serviços:

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

Em todos os nós do cluster, mais e mais novas regras de iptables serão geradas aproximadamente simultaneamente. Além disso, um bilhão de regras de iptables serão geradas para cada serviço.

Verifiquei tudo isso em vários milhares, até dez. E o problema é que já nesse limite é bastante problemático fazer ssh no nó. Porque os pacotes, passando por tantas cadeias, começam a não parecer muito bons.

E tudo isso também é resolvido com a ajuda do Kubernetes. Existe um objeto de cota de recursos. Define o número de recursos e objetos disponíveis para o namespace no cluster. Podemos criar um objeto yaml em cada namespace do cluster Kubernetes. Utilizando este objeto, podemos dizer que temos um certo número de solicitações e limites alocados para este namespace, e então podemos dizer que neste namespace é possível criar 10 serviços e 10 pods. E um único desenvolvedor pode pelo menos se engasgar à noite. Kubernetes dirá a ele: “Você não pode dimensionar seus pods para esse valor, porque o recurso excede a cota”. É isso, problema resolvido. Documentação aqui.

Um ponto problemático surge a esse respeito. Você sente como está se tornando difícil criar um namespace no Kubernetes. Para criá-lo, precisamos levar muitas coisas em consideração.

Cota de recursos + Faixa de limite + RBAC
• Crie um espaço para nome
• Crie um intervalo limite dentro
• Criar dentro de resourcequota
• Crie uma conta de serviço para CI
• Criar rolebinding para CI e usuários
• Opcionalmente, inicie os pods de serviço necessários

Portanto, gostaria de aproveitar esta oportunidade para compartilhar meus desenvolvimentos. Existe algo chamado operador SDK. Esta é uma maneira de um cluster Kubernetes escrever operadores para ele. Você pode escrever instruções usando Ansible.

No início foi escrito em Ansible, depois vi que havia um operador SDK e reescrevi a função Ansible em um operador. Esta instrução permite criar um objeto no cluster Kubernetes chamado comando. Dentro de um comando, permite descrever o ambiente para este comando em yaml. E dentro do ambiente de equipe nos permite descrever que estamos alocando tantos recursos.

Um pequeno tornando todo esse processo complexo mais fácil.

E para concluir. O que fazer com tudo isso?
Primeiro. A política de segurança do pod é boa. E apesar de nenhum dos instaladores do Kubernetes usá-los até hoje, você ainda precisa usá-los em seus clusters.

A Política de Rede não é apenas mais um recurso desnecessário. Isso é o que realmente é necessário em um cluster.

LimitRange/ResourceQuota - é hora de usá-lo. Começamos a usar isso há muito tempo e por muito tempo tive certeza de que todo mundo estava usando. Acontece que isso é raro.

Além do que mencionei durante o relatório, existem recursos não documentados que permitem atacar o cluster. Lançado recentemente análise extensiva de vulnerabilidades do Kubernetes.

Algumas coisas são tão tristes e dolorosas. Por exemplo, sob certas condições, os cubelets em um cluster Kubernetes podem fornecer o conteúdo do diretório warlocks a um usuário não autorizado.

Aqui Há instruções sobre como reproduzir tudo o que eu disse. Existem arquivos com exemplos de produção da aparência de ResourceQuota e Pod Security Policy. E você pode tocar em tudo isso.

Obrigado a todos.

Fonte: habr.com