{"id":39203,"date":"2019-10-31T22:28:25","date_gmt":"2019-10-31T19:28:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf\/"},"modified":"2019-10-31T22:28:25","modified_gmt":"2019-10-31T19:28:25","slug":"zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Fechando as brechas no cluster Kubernetes. Apresenta\u00e7\u00e3o e transcri\u00e7\u00e3o do DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, arquiteto de solu\u00e7\u00f5es da Southbridge e instrutor do Sloerm, apresentou uma palestra na DevOpsConf 2019. Esta palestra \u00e9 parte de um dos temas do curso avan\u00e7ado em Kubernetes \"Sloerm Mega\".<\/p>\n

<\/p>\n

Sloerm B\u00e1sico: introdu\u00e7\u00e3o ao Kubernetes<\/a><\/noindex> acontece em Moscovo de 18 a 20 de novembro.
\nSloerm Mega: uma vis\u00e3o interna do Kubernetes<\/a><\/noindex> \u2014 Moscovo, de 22 a 24 de novembro.
\nSloerm Online: ambos os cursos sobre Kubernetes<\/a><\/noindex> dispon\u00edvel a qualquer momento.<\/p>\n

\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Abaixo, est\u00e1 a transcri\u00e7\u00e3o da palestra.<\/p>\n

<\/a><\/noindex><\/p>\n

Bom dia, colegas e simpatizantes. Hoje, vou falar sobre seguran\u00e7a.<\/p>\n

<\/p>\n

Vejo que h\u00e1 muitos profissionais de seguran\u00e7a na sala hoje. Pe\u00e7o desculpas antecipadamente se usar termos do mundo da seguran\u00e7a de uma maneira que n\u00e3o seja a habitual para voc\u00eas. <\/p>\n

<\/p>\n

H\u00e1 cerca de seis meses, coloquei as m\u00e3os em um cluster Kubernetes p\u00fablico. P\u00fablico significa que existem um certo n\u00famero de namespaces, nesses namespaces h\u00e1 usu\u00e1rios, isolados em seus pr\u00f3prios namespaces. Todos esses usu\u00e1rios pertencem a diferentes empresas. E, supunha-se que esse cluster deveria ser usado como CDN. Ou seja, voc\u00ea recebe um cluster, recebe um usu\u00e1rio, voc\u00ea entra no seu namespace e faz o deploy das suas aplica\u00e7\u00f5es front-end. <\/p>\n

<\/p>\n

A minha empresa anterior tentou vender um servi\u00e7o desse tipo. E pediram-me para testar o cluster para ver se essa solu\u00e7\u00e3o era adequada. <\/p>\n

<\/p>\n

Entrei nesse cluster. Recebi direitos limitados e um namespace restrito. As pessoas l\u00e1 entendiam o que era seguran\u00e7a. Elas estavam cientes do que era o controle de acesso baseado em fun\u00e7\u00e3o (RBAC) do Kubernetes \u2014 e configuraram de tal forma que eu n\u00e3o conseguia iniciar pods separadamente dos deployments. N\u00e3o me lembro da tarefa que estava tentando resolver, iniciando um pod sem um deployment, mas realmente queria simplesmente iniciar um pod. Decidi verificar quais direitos eu tinha no cluster, o que eu podia fazer, o que n\u00e3o podia, e o que eles estavam fazendo de errado no RBAC. <\/p>\n

<\/p>\n

Acabei de forma que, em dois minutos, consegui o acesso de administrador ao cluster deles, olhei todos os namespaces vizinhos e vi l\u00e1 aplica\u00e7\u00f5es front-end de produ\u00e7\u00e3o de empresas que j\u00e1 compraram o servi\u00e7o e fizeram o deploy. Eu mal consegui me controlar para n\u00e3o ir a uma das front-ends e colocar uma palavra ofensiva na p\u00e1gina inicial. <\/p>\n

<\/p>\n

Vou falar com exemplos de como fiz isso e como \u00e9 preciso se proteger contra isso. <\/p>\n

<\/p>\n

Mas antes, deixem-me apresentar. Meu nome \u00e9 Pavel Selivanov. Sou arquiteto da empresa Southbridge. Eu entendo de Kubernetes, DevOps e coisas modernas. N\u00f3s, engenheiros da Southbridge, constru\u00edmos tudo isso, enquanto eu consulto. <\/p>\n

<\/p>\n

Al\u00e9m da atividade principal, recentemente lan\u00e7amos projetos chamados Sl\u00ebrmy. Estamos tentando trazer um pouco da nossa habilidade em trabalhar com Kubernetes para as massas, ensinando outras pessoas a tamb\u00e9m trabalhar com K8s. <\/p>\n

<\/p>\n

Sobre o que vou falar hoje. O tema da apresenta\u00e7\u00e3o \u00e9 \u00f3bvio \u2014 sobre a seguran\u00e7a do cluster Kubernetes. Mas quero deixar claro que este \u00e9 um tema muito amplo \u2014 e por isso, quero esclarecer do que definitivamente n\u00e3o falarei. N\u00e3o falarei sobre termos batidos que j\u00e1 foram triturados na internet. Coisas como RBAC e certificados. <\/p>\n

<\/p>\n

Vou falar sobre o que eu e meus colegas sentimos em rela\u00e7\u00e3o \u00e0 seguran\u00e7a no cluster Kubernetes. Vemos esses problemas tanto em provedores que oferecem clusters Kubernetes quanto em clientes que nos procuram. E at\u00e9 em clientes que v\u00eam at\u00e9 n\u00f3s de outras empresas de consultoria. Ou seja, a magnitude da trag\u00e9dia \u00e9 realmente grande. <\/p>\n

<\/p>\n

Literalmente tr\u00eas pontos que vou abordar hoje: <\/p>\n

<\/p>\n

    \n
  1. Direitos dos usu\u00e1rios vs direitos dos pods. Os direitos dos usu\u00e1rios e os direitos dos pods n\u00e3o s\u00e3o a mesma coisa. <\/li>\n
  2. Coleta de informa\u00e7\u00f5es sobre o cluster. Vou mostrar que \u00e9 poss\u00edvel coletar todas as informa\u00e7\u00f5es do cluster que s\u00e3o necess\u00e1rias, sem ter permiss\u00f5es especiais nesse cluster. <\/li>\n
  3. Ataque DoS ao cluster. Se n\u00e3o conseguirmos coletar informa\u00e7\u00f5es, poderemos derrubar o cluster de qualquer forma. Vou falar sobre ataques DoS aos componentes de controle do cluster. <\/li>\n<\/ol>\n

    <\/p>\n

    Outra coisa geral que mencionarei \u2014 em que testei tudo isso, que com certeza posso afirmar que tudo funciona.<\/p>\n

    <\/p>\n

    Tomamos como base a instala\u00e7\u00e3o do cluster Kubernetes usando o Kubespray. Se algu\u00e9m n\u00e3o sabe, isso \u00e9, na verdade, um conjunto de fun\u00e7\u00f5es para Ansible. N\u00f3s o usamos constantemente em nosso trabalho. \u00c9 bom porque pode ser implantado em qualquer lugar \u2014 tanto em hardware quanto em nuvem. Um m\u00e9todo de instala\u00e7\u00e3o \u00e9, basicamente, adequado para tudo. <\/p>\n

    <\/p>\n

    Neste cluster, terei Kubernetes v1.14.5. Todo o cluster Kube que iremos considerar \u00e9 dividido em namespaces, cada namespace pertence a uma equipe separada, e cada namespace tem acesso concedido aos membros dessa equipe. Eles n\u00e3o podem acessar outros namespaces, apenas o seu pr\u00f3prio. Mas existe uma conta de administrador que possui direitos sobre todo o cluster. <\/p>\n

    <\/p>\n

    \"Fechando<\/p>\n

    <\/p>\n

    Eu prometi que o primeiro passo seria obter direitos administrativos no cluster. Precisamos de um pod especialmente preparado que vai comprometer o cluster Kubernetes. Tudo o que precisamos fazer \u00e9 aplic\u00e1-lo no cluster Kubernetes. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Este pod chegar\u00e1 a um dos mestres do cluster Kubernetes. E o cluster nos devolver\u00e1 com alegria um arquivo chamado admin.conf. Este arquivo cont\u00e9m todos os certificados do administrador e tamb\u00e9m configura o API do cluster. \u00c9 assim que podemos obter acesso administrativo, acho que em 98% dos clusters Kubernetes. <\/p>\n
    <\/p>\n
    Para reiterar, este pod foi criado por um desenvolvedor em seu cluster, que tinha acesso para implantar suas propostas em um pequeno namespace, estando totalmente restringido por RBAC. Ele n\u00e3o tinha nenhum direito. No entanto, o certificado foi retornado. <\/p>\n
    <\/p>\n
    Agora vamos falar sobre o pod especialmente preparado. Vamos execut\u00e1-lo em qualquer imagem. Para exemplo, tomaremos debian:jessie. <\/p>\n
    <\/p>\n
    Temos algo assim: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    O que \u00e9 toleration? Os mestres no cluster Kubernetes geralmente s\u00e3o marcados com uma coisa chamada taint (\"contamina\u00e7\u00e3o\" em ingl\u00eas). A ess\u00eancia dessa \"contamina\u00e7\u00e3o\" \u00e9 que os pods n\u00e3o podem ser alocados nos n\u00f3s mestres. Mas nada impede que em qualquer pod se indique que ele \u00e9 tolerante a essa \"contamina\u00e7\u00e3o\". A se\u00e7\u00e3o Toleration diz que se um n\u00f3 tiver NoSchedule, nosso pod \u00e9 tolerante a essa contamina\u00e7\u00e3o e n\u00e3o haver\u00e1 problemas. <\/p>\n
    <\/p>\n
    Em seguida, dizemos que nosso pod n\u00e3o \u00e9 apenas tolerante, mas tamb\u00e9m deseja especificamente ser alocado em um mestre. Porque nos mestres est\u00e1 o que precisamos \u2014 todos os certificados. Portanto, dizemos nodeSelector \u2014 e temos um r\u00f3tulo padr\u00e3o nos mestres que permite escolher entre todos os n\u00f3s do cluster aqueles que s\u00e3o mestres. <\/p>\n
    <\/p>\n
    Com essas duas se\u00e7\u00f5es, o pod certamente ser\u00e1 alocado no mestre. E ele ter\u00e1 permiss\u00e3o para residir l\u00e1. <\/p>\n
    <\/p>\n
    Mas simplesmente chegar ao mestre n\u00e3o \u00e9 suficiente. Isso n\u00e3o nos dar\u00e1 nada. Portanto, em seguida, temos duas coisas assim:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Indicamos que nosso pod, que estamos lan\u00e7ando, viver\u00e1 no namespace do n\u00facleo, no namespace de rede e no namespace PID. Assim que o pod for iniciado no master, ele poder\u00e1 ver todas as interfaces reais e ativas desse n\u00f3, escutar todo o tr\u00e1fego e ver o PID de todos os processos.<\/p>\n
    <\/p>\n
    A partir da\u00ed, \u00e9 simples. Voc\u00ea pega o etcd e l\u00ea o que quiser. <\/p>\n
    <\/p>\n
    O mais interessante \u00e9 essa funcionalidade do Kubernetes, que est\u00e1 l\u00e1 por padr\u00e3o. <\/p>\n
    <\/p>\n
    volumeMounts:\n- mountPath: \/host \n  name: host \nvolumes:\n- hostPath: \n    path: \/ \n    type: Directory \n  name: host <\/code><\/pre>\n
    <\/p>\n
    E a ess\u00eancia disso \u00e9 que podemos, no pod que estamos lan\u00e7ando, mesmo sem privil\u00e9gios sobre esse cluster, declarar que queremos criar um volume do tipo hostPath. Ou seja, pegar o caminho do host em que vamos executar \u2014 e us\u00e1-lo como volume. Em seguida, o nomeamos como name: host. Todo esse hostPath \u00e9 montado dentro do pod. Neste exemplo, no diret\u00f3rio \/host. <\/p>\n
    <\/p>\n
    Vou repetir. Dissemos ao pod para ir ao master, obter hostNetwork e hostPID \u2014 e montar toda a raiz do master dentro desse pod. <\/p>\n
    <\/p>\n
    Voc\u00ea entende que no Debian temos o bash em execu\u00e7\u00e3o, e esse bash est\u00e1 funcionando como root. Ou seja, acabamos de obter acesso root ao master, sem ter quaisquer direitos no cluster Kubernetes.<\/p>\n
    <\/p>\n
    A pr\u00f3xima tarefa \u00e9 entrar no pod no diret\u00f3rio \/host \/etc\/kubernetes\/pki, se n\u00e3o me engano, pegar todos os certificados de mestre do cluster e, consequentemente, tornar-se o administrador do cluster. <\/p>\n
    <\/p>\n
    Se olharmos bem, estes s\u00e3o alguns dos direitos mais perigosos nos pods \u2014 independentemente dos direitos que o usu\u00e1rio possui:
    \n\"Fechando<\/p>\n
    <\/p>\n
    Se eu tenho privil\u00e9gios para iniciar um pod em um namespace do cluster, esse pod tem esses direitos por padr\u00e3o. Eu posso iniciar pods privilegiados, e isso \u00e9 basicamente ter todos os direitos, praticamente como root no n\u00f3. <\/p>\n
    <\/p>\n
    Meu favorito \u2014 o Root user. E o Kubernetes tem uma op\u00e7\u00e3o chamada Run As Non-Root. \u00c9 uma esp\u00e9cie de prote\u00e7\u00e3o contra hackers. Voc\u00ea sabe o que \u00e9 um 'v\u00edrus moldavo'? Se voc\u00ea, de alguma forma, \u00e9 um hacker e entrou no meu cluster Kubernetes, n\u00f3s, pobres administradores, pedimos: 'Por favor, especifique em seus pods, com os quais voc\u00ea ir\u00e1 hackear meu cluster, run as non-root. Caso contr\u00e1rio, voc\u00ea pode iniciar um processo em seu pod como root, e ser\u00e1 muito f\u00e1cil me hackear. Proteja-se, por favor, de si mesmo'. <\/p>\n
    <\/p>\n
    O volume de caminho do host \u2014 na minha opini\u00e3o, \u00e9 a maneira mais r\u00e1pida de obter o resultado desejado do cluster Kubernetes. <\/p>\n
    <\/p>\n
    Mas o que fazer com tudo isso? <\/p>\n
    <\/p>\n
    Pensamentos que devem vir \u00e0 mente de qualquer administrador normal ao lidar com Kubernetes: \u201cAh, eu disse que o Kubernetes n\u00e3o funciona. Tem falhas. E tudo isso \u00e9 uma droga\u201d. Na verdade, existe algo chamado documenta\u00e7\u00e3o, e se voc\u00ea olhar para l\u00e1, h\u00e1 uma se\u00e7\u00e3o Pol\u00edtica de Seguran\u00e7a de Pod<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Este \u00e9 um objeto YAML - podemos cri\u00e1-lo no cluster Kubernetes - que controla aspectos de seguran\u00e7a especificamente na descri\u00e7\u00e3o dos pods. Ou seja, na pr\u00e1tica, ele controla os direitos de uso de v\u00e1rias coisas, como hostNetwork, hostPID, certos tipos de volume, que existem nos pods durante a execu\u00e7\u00e3o. Com a Pol\u00edtica de Seguran\u00e7a de Pod, tudo isso pode ser descrito. <\/p>\n
    <\/p>\n
    O mais interessante sobre a Pol\u00edtica de Seguran\u00e7a de Pod \u00e9 que no cluster Kubernetes, todos os instaladores de PSP n\u00e3o est\u00e3o simplesmente descritos de forma alguma; eles est\u00e3o simplesmente desativados por padr\u00e3o. A Pol\u00edtica de Seguran\u00e7a de Pod \u00e9 ativada por meio de um plugin de admission.<\/p>\n
    <\/p>\n
    Ok, vamos implantar a Pol\u00edtica de Seguran\u00e7a de Pod no cluster, digamos que temos alguns pods de servi\u00e7o no namespace, aos quais apenas os administradores t\u00eam acesso. Vamos dizer que todos os outros pods t\u00eam direitos limitados. Porque provavelmente os desenvolvedores n\u00e3o precisam executar pods privilegiados no seu cluster. <\/p>\n
    <\/p>\n
    E parece que est\u00e1 tudo bem. E nosso cluster Kubernetes n\u00e3o pode ser hackeado em dois minutos. <\/p>\n
    <\/p>\n
    H\u00e1 um problema. Provavelmente, se voc\u00ea tiver um cluster Kubernetes, ter\u00e1 um monitoramento instalado nele. Eu at\u00e9 me atrevo a prever que se houver monitoramento no seu cluster, ele se chama Prometheus. <\/p>\n
    <\/p>\n
    O que vou dizer agora ser\u00e1 v\u00e1lido tanto para o operador do Prometheus quanto para o Prometheus instalado em sua forma pura. A quest\u00e3o \u00e9 que se eu n\u00e3o consigo obter rapidamente um administrador no cluster, isso significa que preciso procurar mais. E posso fazer essa busca usando seu monitoramento.<\/p>\n
    <\/p>\n
    Provavelmente, todos leram os mesmos artigos no Habr, e o monitoramento est\u00e1 no namespace monitoring. O Helm chart de todos \u00e9 chamado de forma semelhante. Presumo que se voc\u00ea fizer helm install stable\/prometheus, os nomes ser\u00e3o aproximadamente os mesmos. E, provavelmente, o nome DNS no seu cluster eu n\u00e3o precisarei adivinhar. Porque \u00e9 padr\u00e3o. <\/p>\n
    <\/p>\n
    \"Fechando<\/p>\n
    <\/p>\n
    Em seguida, temos um namespace dev, onde \u00e9 poss\u00edvel iniciar um pod. E depois desse pod, \u00e9 muito f\u00e1cil fazer assim: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics \u00e9 um dos exportadores do Prometheus que coleta m\u00e9tricas da API do Kubernetes. H\u00e1 uma grande quantidade de dados sobre o que est\u00e1 rodando no seu cluster, como est\u00e1 esse ambiente e quais problemas voc\u00ea tem com ele. <\/p>\n
    <\/p>\n
    Como um exemplo simples: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\u00abkube-system\u00bb,pod=\u00abkube-apiserver-k8s-1\u00bb,container=\u00abkube-apiserver\u00bb,image= <\/p>\n
    <\/p>\n
    \u00abgcr.io\/google-containers\/kube-apiserver:v1.14.5\u00bb <\/strong><\/p>\n
    <\/p>\n
    ,image_id=\u00abdocker-pullable:\/\/gcr.io\/google-containers\/kube-apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989\u00bb,container_id=\u00abdocker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b\u00bb} 1 <\/p>\n
    <\/p>\n
    Fazendo uma simples requisi\u00e7\u00e3o curl de um pod n\u00e3o privilegiado, voc\u00ea pode obter essas informa\u00e7\u00f5es. Se voc\u00ea n\u00e3o sabe em qual vers\u00e3o do Kubernetes est\u00e1 rodando, ele pode facilmente informar voc\u00ea. <\/p>\n
    <\/p>\n
    E a parte mais interessante \u00e9 que, al\u00e9m de acessar o kube-state-metrics, voc\u00ea tamb\u00e9m pode acessar diretamente o Prometheus com a mesma efic\u00e1cia. Voc\u00ea pode coletar m\u00e9tricas de l\u00e1. Voc\u00ea pode at\u00e9 construir m\u00e9tricas a partir dali. Teoricamente, voc\u00ea poderia elaborar uma requisi\u00e7\u00e3o do cluster para o Prometheus que simplesmente o desligaria. E seu monitoramento pararia completamente de funcionar. <\/p>\n
    <\/p>\n
    E aqui surge a quest\u00e3o: algum monitoramento externo est\u00e1 monitorando o seu monitoramento? Acabei de conseguir atuar no cluster do Kubernetes sem consequ\u00eancias para mim. Voc\u00ea nem vai saber que estou l\u00e1, pois o monitoramento j\u00e1 n\u00e3o existe. <\/p>\n
    <\/p>\n
    Da mesma forma que com o PSP, d\u00e1 a sensa\u00e7\u00e3o de que o problema \u00e9 que todas essas tecnologias modernas \u2014 Kubernetes, Prometheus \u2014 simplesmente n\u00e3o funcionam e est\u00e3o cheias de buracos. Na verdade, n\u00e3o \u00e9 isso. <\/p>\n
    <\/p>\n
    H\u00e1 uma coisa chamada \u2014 Pol\u00edtica de Rede<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Se voc\u00ea \u00e9 um bom administrador, provavelmente sabe que a Pol\u00edtica de Rede \u00e9 apenas mais um yaml, que j\u00e1 existem muitos no cluster. E algumas Pol\u00edticas de Rede definitivamente n\u00e3o s\u00e3o necess\u00e1rias. E mesmo que voc\u00ea tenha lido o que \u00e9 uma Pol\u00edtica de Rede, que se trata de um firewall em yaml do Kubernetes, que permite restringir os direitos de acesso entre namespaces e entre pods, voc\u00ea deve ter decidido que um firewall em formato yaml no Kubernetes \u00e9 apenas mais uma das abstra\u00e7\u00f5es... N\u00e3o, isso definitivamente n\u00e3o \u00e9 necess\u00e1rio. <\/p>\n
    <\/p>\n
    Mesmo que seus especialistas de seguran\u00e7a n\u00e3o tenham sido informados de que \u00e9 poss\u00edvel construir, de maneira muito simples, um firewall granulado com seu Kubernetes, se eles ainda n\u00e3o souberem disso e n\u00e3o te pressionarem: \"Ent\u00e3o, pode passar, pode passar...\". De qualquer forma, voc\u00ea precisar\u00e1 da Network Policy para restringir o acesso a alguns locais administrativos que podem ser acessados do seu cluster sem qualquer autoriza\u00e7\u00e3o. <\/p>\n
    <\/p>\n
    Como no exemplo que mencionei, \u00e9 poss\u00edvel acessar os kube state metrics de qualquer namespace no cluster Kubernetes, sem ter direitos para isso. As pol\u00edticas de rede restringiram o acesso de todos os outros namespaces ao namespace de monitoramento e com isso: sem acesso, sem problemas. Em todos os charts dispon\u00edveis, tanto do Prometheus padr\u00e3o quanto do Prometheus do operador, h\u00e1 simplesmente uma op\u00e7\u00e3o na values do Helm que permite ativar pol\u00edticas de rede para eles. Basta habilitar e elas funcionar\u00e3o. <\/p>\n
    <\/p>\n
    Aqui, na verdade, h\u00e1 um problema. Sendo um bom administrador, voc\u00ea provavelmente decidiu que as pol\u00edticas de rede n\u00e3o s\u00e3o necess\u00e1rias. E, ap\u00f3s ler v\u00e1rios artigos em sites como o Habr, voc\u00ea chegou \u00e0 conclus\u00e3o de que o flannel, especialmente no modo host-gateway, \u00e9 a melhor op\u00e7\u00e3o que voc\u00ea pode escolher. <\/p>\n
    <\/p>\n
    O que fazer? <\/p>\n
    <\/p>\n
    Voc\u00ea pode tentar redesplegar a solu\u00e7\u00e3o de rede que est\u00e1 em seu cluster Kubernetes e substitu\u00ed-la por algo mais funcional. Por exemplo, pelo Calico. Mas, quero avisar imediatamente, a tarefa de mudar a solu\u00e7\u00e3o de rede em um cluster Kubernetes em funcionamento n\u00e3o \u00e9 nada trivial. Eu j\u00e1 resolvi isso duas vezes (ambas teoricamente), mas at\u00e9 mesmo em nossas apresenta\u00e7\u00f5es mostramos como fazer. Para nossos alunos, demonstramos como mudar a solu\u00e7\u00e3o de rede no cluster Kubernetes. Basicamente, voc\u00ea pode tentar fazer isso de modo que n\u00e3o haja downtime no cluster de produ\u00e7\u00e3o. Mas provavelmente voc\u00ea n\u00e3o conseguir\u00e1. <\/p>\n
    <\/p>\n
    E o problema, na verdade, \u00e9 resolvido de forma muito simples. No cluster, existem certificados, e voc\u00ea sabe que os certificados v\u00e3o expirar em um ano. Normalmente, a solu\u00e7\u00e3o padr\u00e3o para os certificados em um cluster \u00e9 a seguinte: por que nos preocuparmos? Vamos levantar um novo cluster ao lado, o antigo pode expirar, e fazemos tudo de novo. \u00c9 verdade que, quando ele expirar, teremos um dia que ficar\u00e1 inativo, mas ao menos teremos um novo cluster. <\/p>\n
    <\/p>\n
    Quando voc\u00ea for levantar o novo cluster, aproveite e insira o Calico no lugar do flannel. <\/p>\n
    <\/p>\n
    O que fazer se voc\u00ea tiver certificados emitidos para cem anos e n\u00e3o pretende reprovisionar o cluster? Existe uma ferramenta chamada Kube-RBAC-Proxy. \u00c9 uma excelente solu\u00e7\u00e3o que permite ser integrada como um container sidecar a qualquer pod no cluster Kubernetes. E, na pr\u00e1tica, ela adiciona autentica\u00e7\u00e3o via RBAC do pr\u00f3prio Kubernetes a esse pod. <\/p>\n
    <\/p>\n
    H\u00e1 um problema. Anteriormente, a solu\u00e7\u00e3o Kube-RBAC-Proxy estava integrada no operador do Prometheus. Mas isso n\u00e3o existe mais. As vers\u00f5es modernas agora pressup\u00f5em que voc\u00ea tenha uma pol\u00edtica de rede e a utilize para restringir o acesso. Portanto, ser\u00e1 necess\u00e1rio reescrever um pouco o chart. Na verdade, se voc\u00ea acessar este reposit\u00f3rio<\/a><\/noindex>, l\u00e1 voc\u00ea encontrar\u00e1 exemplos de como us\u00e1-lo como sidecars, e os charts precisar\u00e3o ser reescritos no m\u00ednimo. <\/p>\n
    <\/p>\n
    H\u00e1 mais um pequeno problema. N\u00e3o apenas o Prometheus exp\u00f5e suas m\u00e9tricas indiscriminadamente. Todos os componentes do cluster Kubernetes tamb\u00e9m podem expor suas pr\u00f3prias m\u00e9tricas. <\/p>\n
    <\/p>\n
    Mas, como j\u00e1 mencionei, se voc\u00ea n\u00e3o consegue acessar o cluster e coletar informa\u00e7\u00f5es, pelo menos pode causar algum dano. <\/p>\n
    <\/p>\n
    Ent\u00e3o, vou rapidamente mostrar duas maneiras de como voc\u00ea pode prejudicar a sa\u00fade de um cluster Kubernetes. <\/p>\n
    <\/p>\n
    Voc\u00eas v\u00e3o rir quando eu contar, s\u00e3o dois casos da vida real. <\/p>\n
    <\/p>\n
    Primeiro m\u00e9todo. Esgotamento de recursos. <\/p>\n
    <\/p>\n
    Vamos iniciar mais um pod especial. Ele ter\u00e1 esta se\u00e7\u00e3o. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Como voc\u00ea sabe, requests s\u00e3o a quantidade de CPU e mem\u00f3ria que s\u00e3o reservadas no host para pods espec\u00edficos com requisi\u00e7\u00f5es. Se temos um host quad-core no cluster Kubernetes, e chega um pod com requisi\u00e7\u00f5es de quatro CPUs, isso significa que nenhum outro pod com requisi\u00e7\u00f5es conseguir\u00e1 ser alocado nesse host. <\/p>\n
    <\/p>\n
    Se eu iniciar esse pod e depois executar o comando: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Ent\u00e3o, ningu\u00e9m mais conseguir\u00e1 ser implantado no cluster Kubernetes. Porque todos os n\u00f3s ficar\u00e3o sem requisi\u00e7\u00f5es. Dessa forma, eu poderei parar o seu cluster Kubernetes. Se eu fizer isso \u00e0 noite, os deployments poder\u00e3o ficar interrompidos por um bom tempo. <\/p>\n
    <\/p>\n
    Se olharmos mais uma vez para a documenta\u00e7\u00e3o do Kubernetes, veremos algo chamado Limit Range. Ele estabelece recursos para objetos do cluster. Voc\u00ea pode escrever um objeto Limit Range em YAML, aplic\u00e1-lo a namespaces espec\u00edficos \u2014 e assim, nesse namespace, voc\u00ea pode especificar que possui recursos padr\u00e3o, m\u00e1ximos e m\u00ednimos para os pods.<\/p>\n
    <\/p>\n
    Com essa ferramenta, podemos restringir os usu\u00e1rios em namespaces de produtos espec\u00edficos das equipes em suas capacidades de indicar coisas indesejadas em seus pods. Mas, infelizmente, mesmo que voc\u00ea avise um usu\u00e1rio para n\u00e3o lan\u00e7ar pods com requisi\u00e7\u00f5es superiores a um CPU, existe um comando maravilhoso chamado scale, ou atrav\u00e9s do painel eles podem realizar o scale.<\/p>\n
    <\/p>\n
    E a partir da\u00ed surge o segundo m\u00e9todo. Lan\u00e7amos 11 111 111 111 111 pods. Isso \u00e9 onze bilh\u00f5es. N\u00e3o \u00e9 porque eu inventei esse n\u00famero, mas porque eu mesmo presenciei isso. <\/p>\n
    <\/p>\n
    Uma hist\u00f3ria real. No final da noite, eu j\u00e1 estava prestes a sair do escrit\u00f3rio. Olhei, e em um canto havia um grupo de desenvolvedores fazendo algo freneticamente com seus laptops. Fui at\u00e9 os caras e perguntei: \"O que aconteceu com voc\u00eas?\"<\/p>\n
    <\/p>\n
    Um pouco antes, por volta das nove da noite, um dos desenvolvedores estava se preparando para ir para casa. E decidiu: \"Agora eu vou escalar meu aplicativo para um\". Ele pressionou um, mas a internet estava um pouco lenta. Ele pressionou mais uma vez, apertou o um, clicou no Enter. Tentou tudo que podia. Ent\u00e3o a internet respondeu \u2014 e tudo come\u00e7ou a escalar para esse n\u00famero. <\/p>\n
    <\/p>\n
    Na verdade, essa hist\u00f3ria n\u00e3o aconteceu no Kubernetes, na \u00e9poca era o Nomad. Isso terminou ap\u00f3s uma hora de tentativas de impedir que o Nomad de insistentes tentativas de escalar; o Nomad respondeu que n\u00e3o pararia de escalar e n\u00e3o faria mais nada. \"Estou cansado, vou embora\". E encerrou. <\/p>\n
    <\/p>\n
    Naturalmente, eu tentei fazer o mesmo no Kubernetes. Onze bilh\u00f5es de pods n\u00e3o agradaram o Kubernetes, ele disse: \"N\u00e3o posso. Excede os limites internos\". Mas 1 000 000 000 de pods funcionaram. <\/p>\n
    <\/p>\n
    Em resposta a um bilh\u00e3o de Pods, ele realmente come\u00e7ou a escalar. Quanto mais o processo avan\u00e7ava, mais tempo levava para criar novos Pods. Mas o processo continuava. O \u00fanico problema \u00e9 que, se eu posso lan\u00e7ar Pods ilimitadamente em meu namespace, mesmo sem solicita\u00e7\u00f5es e limites, posso criar tantos Pods com algumas tarefas que, com essas tarefas, os n\u00f3s come\u00e7am a ficar sobrecarregados em termos de mem\u00f3ria e CPU. Quando eu lan\u00e7o tantos Pods, as informa\u00e7\u00f5es delas precisam ser armazenadas, ou seja, no etcd. E quando informa\u00e7\u00f5es demais chegam l\u00e1, o armazenamento come\u00e7a a ficar muito lento \u2014 e o Kubernetes come\u00e7a a enfrentar lat\u00eancias. <\/p>\n
    <\/p>\n
    E h\u00e1 outro problema... Como voc\u00eas sabem, os componentes de controle do Kubernetes n\u00e3o s\u00e3o uma \u00fanica pe\u00e7a central, mas sim v\u00e1rios componentes. Ali, em particular, h\u00e1 o controlador de ger\u00eancia, o scheduler e assim por diante. Todos esses caras come\u00e7am a realizar simultaneamente um trabalho desnecess\u00e1rio que, com o tempo, vai demandar cada vez mais tempo. O controlador de ger\u00eancia vai criar novos Pods. O scheduler tentar\u00e1 encontrar um novo n\u00f3 para eles. \u00c9 prov\u00e1vel que os novos n\u00f3s em seu cluster acabem logo. O cluster do Kubernetes come\u00e7ar\u00e1 a funcionar cada vez mais devagar.<\/p>\n
    <\/p>\n
    Mas eu decidi ir ainda mais longe. Como voc\u00ea sabe, no Kubernetes h\u00e1 algo que se chama servi\u00e7o. E, por padr\u00e3o, em seus clusters, o servi\u00e7o provavelmente funciona com tabelas IP. <\/p>\n
    <\/p>\n
    Se eu lan\u00e7ar bilh\u00f5es de Pods, por exemplo, e depois usar um script para fazer o Kubernetes criar novos servi\u00e7os: <\/p>\n
    <\/p>\n
    for i in {1..1111111}; do\n    kubectl expose deployment test --port 80  \n        --overrides=\"{\"apiVersion\": \"v1\", \n           \"metadata\": {\"name\": \"nginx$i\"}}\"; \ndone <\/code><\/pre>\n
    <\/p>\n
    Em todos os n\u00f3s do cluster, aproximadamente ao mesmo tempo, novas regras de iptables estar\u00e3o sendo geradas. E para cada servi\u00e7o, ser\u00e3o geradas um bilh\u00e3o de regras de iptables. <\/p>\n
    <\/p>\n
    Eu testei tudo isso com alguns milhares, at\u00e9 uma dezena. E o problema \u00e9 que, j\u00e1 nessa quantidade, conectar via ssh a um n\u00f3 se torna bastante problem\u00e1tico. Porque os pacotes, ao passar por tantas cadeias, come\u00e7am a ter um desempenho ruim. <\/p>\n
    <\/p>\n
    E isso tamb\u00e9m \u00e9 resolvido com o Kubernetes. Existe um objeto chamado Resource quota. Ele estabelece a quantidade de recursos e objetos dispon\u00edveis para um namespace no cluster. Podemos criar um objeto YAML em cada namespace do cluster Kubernetes. Com esse objeto, podemos dizer que para este namespace foram alocados uma certa quantidade de requisi\u00e7\u00f5es, limites, e depois podemos dizer que neste namespace \u00e9 poss\u00edvel criar 10 servi\u00e7os e 10 pods. E o desenvolvedor pode ficar \u00e0 vontade \u00e0 noite. O Kubernetes dir\u00e1 a ele: \"N\u00e3o \u00e9 poss\u00edvel escalar seus pods para tal quantidade, porque excede a cota de recursos.\" Pronto, problema resolvido. Documenta\u00e7\u00e3o aqui<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Um problema surge a partir disso. Voc\u00ea sente como se fosse dif\u00edcil criar um namespace no Kubernetes. Para cri\u00e1-lo, precisamos considerar uma s\u00e9rie de fatores.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Criamos um namespace
    \n\u2022 Criamos um limitrange dentro dele
    \n\u2022 Criamos um resourcequota dentro dele
    \n\u2022 Criamos um serviceaccount para CI
    \n\u2022 Criamos um rolebinding para CI e usu\u00e1rios
    \n\u2022 Opcionalmente, iniciamos os pods de servi\u00e7o necess\u00e1rios <\/p>\n
    <\/p>\n
    Portanto, aproveitando a oportunidade, gostaria de compartilhar meus desenvolvimentos. Existe uma ferramenta chamada operador SDK. Esse \u00e9 um modo de escrever operadores para o cluster Kubernetes. Voc\u00ea pode escrever operadores com o Ansible.<\/p>\n
    <\/p>\n
    Primeiro n\u00f3s escrevemos em Ansible, e depois eu percebi que existe o operador SDK e reescrevi a fun\u00e7\u00e3o do Ansible como um operador. Esse operador permite criar um objeto no cluster Kubernetes que \u00e9 chamado de comando. Dentro do comando, permite descrever em YAML o ambiente para esse comando, e dentro do ambiente do comando permite descrever que estamos alocando certos recursos. <\/p>\n
    <\/p>\n
    Pequeno facilitador de todo esse processo complexo<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    E em conclus\u00e3o. O que fazer com tudo isso?
    \nPrimeiro. Pod Security Policy \u2014 isso \u00e9 bom. E apesar de nenhum dos instaladores do Kubernetes usar isso at\u00e9 hoje, ainda assim \u00e9 necess\u00e1rio utiliz\u00e1-los em seus clusters. <\/p>\n
    <\/p>\n
    Network Policy \u2014 isso n\u00e3o \u00e9 mais uma funcionalidade desnecess\u00e1ria. \u00c9 algo realmente necess\u00e1rio no cluster. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2014 j\u00e1 est\u00e1 na hora de us\u00e1-los. J\u00e1 estamos utilizando isso h\u00e1 um bom tempo, e eu estava convencido de que todo mundo aplicava isso. Acontece que \u00e9 uma raridade. <\/p>\n
    <\/p>\n
    Al\u00e9m do que mencionei durante a apresenta\u00e7\u00e3o, existem recursos n\u00e3o documentados que permitem atacar o cluster. Recentemente foi divulgado uma grande an\u00e1lise de vulnerabilidades do Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Algumas coisas s\u00e3o t\u00e3o tristes e frustrantes. Como, por exemplo, em certas condi\u00e7\u00f5es, os kubelets no cluster do Kubernetes podem revelar o conte\u00fado do diret\u00f3rio de warlocks, e isso para um usu\u00e1rio n\u00e3o autorizado. <\/p>\n
    <\/p>\n
    Aqui<\/a><\/noindex> existem instru\u00e7\u00f5es sobre como reproduzir tudo o que falei. H\u00e1 arquivos com exemplos de produ\u00e7\u00e3o, como ResourceQuota e Pod Security Policy. E tudo isso pode ser testado. <\/p>\n
    <\/p>\n
    Obrigado a todos.<\/p>\n
    Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29423,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39203","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Estamos tapando as brechas no cluster Kubernetes. Palestra e transcri\u00e7\u00e3o da DevOpsConf | ProHoster","description":"Pavel Selivanov, arquiteto de solu\u00e7\u00f5es da Southbridge e professor do Slyerma, apresentou uma palestra na DevOpsConf 2019.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u0430\u0434\u0435\u043b\u044b\u0432\u0430\u0435\u043c \u0434\u044b\u0440\u044b \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0414\u043e\u043a\u043b\u0430\u0434 \u0438 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0441 DevOpsConf | ProHoster","og:description":"\u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:25+00:00","article:modified_time":"2019-10-31T19:28:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39203","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:43","updated":"2026-01-24 01:15:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}