{"id":36918,"date":"2019-10-31T22:14:43","date_gmt":"2019-10-31T19:14:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bezopasnost-helm\/"},"modified":"2019-10-31T22:14:43","modified_gmt":"2019-10-31T19:14:43","slug":"bezopasnost-helm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/bezopasnost-helm","title":{"rendered":"Seguran\u00e7a do Helm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>A ess\u00eancia da hist\u00f3ria sobre o gerenciador de pacotes mais popular para Kubernetes poderia ser representada com emojis:<\/p>\n<ul>\n<li>caixa \u2014 \u00e9 o Helm (isso \u00e9 o mais apropriado na \u00faltima vers\u00e3o do Emoji);<\/li>\n<li>cadeado \u2014 seguran\u00e7a;<\/li>\n<li>bonequinho \u2014 solu\u00e7\u00e3o do problema.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/91099b372fd73bce94268563c3ee2c50.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNa verdade, tudo ser\u00e1 um pouco mais complicado, e a narrativa est\u00e1 cheia de detalhes t\u00e9cnicos sobre como <b>tornar o Helm seguro.<\/b>.<\/p>\n<ul>\n<li>Em resumo, o que \u00e9 o Helm, caso voc\u00ea n\u00e3o soubesse ou tivesse esquecido. Quais problemas ele resolve e onde ele se encaixa na ecossistema.<\/li>\n<li>Vamos considerar a arquitetura do Helm. Nenhuma conversa sobre seguran\u00e7a e como tornar uma ferramenta ou solu\u00e7\u00e3o mais segura pode deixar de lado a compreens\u00e3o da arquitetura do componente.<\/li>\n<li>Vamos discutir os componentes do Helm.<\/li>\n<li>A pergunta mais candente \u2014 o futuro \u2014 a nova vers\u00e3o do Helm 3.\u00a0<\/li>\n<\/ul>\n<p>\nTudo nesta artigo se refere ao Helm 2. Esta vers\u00e3o atualmente est\u00e1 em produ\u00e7\u00e3o e, provavelmente, \u00e9 esta que voc\u00ea est\u00e1 usando agora, e \u00e9 nela que existem amea\u00e7as \u00e0 seguran\u00e7a.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"_8zNTJ1_R5I\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/_8zNTJ1_R5I\/hqdefault.jpg\" alt=\"Por que no hosting comum a administra\u00e7\u00e3o do PrestaShop \u00e9 lenta, e no seu n\u00e3o \u00e9?\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><br \/>\n<strong>Sobre o palestrante:<\/strong> Alexander Khayorov (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/allexx\/\" class=\"user_link\">allexx<\/a><\/noindex>) tem 10 anos de experi\u00eancia em desenvolvimento, ajudando a melhorar o conte\u00fado <noindex><a rel=\"nofollow\" href=\"https:\/\/conf.python.ru\/2019\">Moscow Python Conf++<\/a><\/noindex> e se juntou ao comit\u00ea <noindex><a rel=\"nofollow\" href=\"https:\/\/events.linuxfoundation.org\/events\/helm-summit-2019\/\">Helm Summit<\/a><\/noindex>. Atualmente trabalha na Chainstack como l\u00edder de desenvolvimento \u2014 um h\u00edbrido entre gerente de desenvolvimento e a pessoa respons\u00e1vel pela entrega de releases finais. Ou seja, est\u00e1 no campo de batalha, onde tudo acontece, desde a cria\u00e7\u00e3o do produto at\u00e9 sua opera\u00e7\u00e3o.<\/p>\n<p>Chainstack \u00e9 uma startup pequena, em r\u00e1pido crescimento, cuja miss\u00e3o \u00e9 permitir que os clientes esque\u00e7am a infraestrutura e as complexidades de operar aplicativos descentralizados, a equipe de desenvolvimento est\u00e1 em Cingapura. N\u00e3o pe\u00e7a para a Chainstack comprar ou vender criptomoedas, mas ofere\u00e7a conversar sobre frameworks de blockchain empresarial, e eles ficar\u00e3o felizes em responder.<\/p>\n<h2>Helm<\/h2>\n<p>\nEste \u00e9 o gerenciador de pacotes (charts) para Kubernetes. A maneira mais clara e vers\u00e1til de trazer aplicativos para o cluster Kubernetes.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/30c0fc1cc1c6ebde97c6e8ec1886ce9f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nRefere-se, \u00e9 claro, a uma abordagem mais estruturada e industrial, em vez de criar seus pr\u00f3prios manifests YAML e escrever pequenas utilidades.<\/p>\n<blockquote><p>O Helm \u00e9 o melhor que existe atualmente em termos de disponibilidade e popularidade.<\/p><\/blockquote>\n<p>\nPor que o Helm? Em primeiro lugar, porque \u00e9 suportado pela CNCF. Cloud Native \u00e9 uma grande organiza\u00e7\u00e3o, que \u00e9 a empresa-m\u00e3e de projetos como Kubernetes, etcd, Fluentd e outros.<\/p>\n<p>Outro fato importante \u00e9 que o Helm \u00e9 um projeto muito popular. Quando em janeiro de 2019 comecei a pensar em como tornar o Helm seguro, o projeto tinha mil estrelas no GitHub. Em maio, j\u00e1 haviam 12 mil.<\/p>\n<p>Muitas pessoas se interessam pelo Helm, ent\u00e3o, mesmo que voc\u00ea ainda n\u00e3o o utilize, o conhecimento sobre sua seguran\u00e7a ser\u00e1 \u00fatil. <strong>A seguran\u00e7a \u00e9 importante.<\/strong><\/p>\n<p>A equipe principal do Helm \u00e9 apoiada pela Microsoft Azure, o que torna este projeto bastante est\u00e1vel, ao contr\u00e1rio de muitos outros. O lan\u00e7amento do Helm 3 Alpha 2 em meados de julho \u00e9 um indicativo de que muitas pessoas est\u00e3o trabalhando no projeto, e elas t\u00eam a vontade e os recursos para desenvolver e melhorar o Helm.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/e53c8e64c3cf5eea3fbd9b0095b0f81e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO Helm resolve v\u00e1rios problemas fundamentais na gest\u00e3o de aplica\u00e7\u00f5es em Kubernetes.<\/p>\n<ul>\n<li>Empacotamento de aplica\u00e7\u00f5es. Mesmo uma aplica\u00e7\u00e3o simples como 'Hello, World' em WordPress j\u00e1 envolve v\u00e1rios servi\u00e7os, e \u00e9 desej\u00e1vel que eles sejam empacotados juntos.<\/li>\n<li>Gest\u00e3o da complexidade que surge com a administra\u00e7\u00e3o dessas aplica\u00e7\u00f5es.<\/li>\n<li>O ciclo de vida que n\u00e3o termina ap\u00f3s a instala\u00e7\u00e3o ou o deployment da aplica\u00e7\u00e3o. Ela continua a existir, precisa ser atualizada, e o Helm ajuda nisso, oferecendo as medidas e pol\u00edticas adequadas.<\/li>\n<\/ul>\n<p>\n<strong>Empacotamento<\/strong> \u00e9 organizado de forma clara: h\u00e1 metadados em total conformidade com o funcionamento de um gerenciador de pacotes comum para Linux, Windows ou MacOS. Ou seja, reposit\u00f3rios, depend\u00eancias de diferentes pacotes, metainforma\u00e7\u00f5es para aplica\u00e7\u00f5es, configura\u00e7\u00f5es, particularidades de configura\u00e7\u00e3o, indexa\u00e7\u00e3o de informa\u00e7\u00f5es, etc. O Helm permite obter e utilizar tudo isso para as aplica\u00e7\u00f5es.<\/p>\n<p><strong>Gest\u00e3o da complexidade<\/strong>. Se voc\u00ea tem muitas aplica\u00e7\u00f5es similares, a parametriza\u00e7\u00e3o se faz necess\u00e1ria. Da\u00ed surgem os templates, mas para n\u00e3o ter que desenvolver sua pr\u00f3pria forma de criar templates, voc\u00ea pode usar o que o Helm oferece pronto.<\/p>\n<p><strong>Gest\u00e3o do ciclo de vida da aplica\u00e7\u00e3o<\/strong> \u2014 na minha opini\u00e3o, essa \u00e9 a quest\u00e3o mais interessante e n\u00e3o resolvida. Foi a raz\u00e3o pela qual eu cheguei ao Helm. Precis\u00e1vamos monitorar o ciclo de vida da aplica\u00e7\u00e3o, quer\u00edamos transferir nosso CI\/CD e ciclos de aplica\u00e7\u00f5es para essa nova abordagem.<\/p>\n<p>O Helm permite:<\/p>\n<ul>\n<li>gerenciar deployments, introduz o conceito de configura\u00e7\u00e3o e revis\u00f5es;<\/li>\n<li>realizar rollback com sucesso;<\/li>\n<li>usar hooks para diferentes eventos;<\/li>\n<li>adicionar verifica\u00e7\u00f5es adicionais para as aplica\u00e7\u00f5es e reagir a seus resultados.<\/li>\n<\/ul>\n<p>\nAl\u00e9m disso <strong>o Helm tem 'baterias'<\/strong> \u2014 uma enorme quantidade de coisas deliciosas que podem ser inclu\u00eddas como plugins, facilitando a sua vida. Os plugins podem ser escritos por conta pr\u00f3pria, eles s\u00e3o bastante isolados e n\u00e3o requerem uma arquitetura rigorosa. Se voc\u00ea deseja implementar algo, recomendo faz\u00ea-lo como um plugin e, depois, possivelmente inclu\u00ed-lo no upstream.<\/p>\n<p>O Helm baseia-se em tr\u00eas conceitos principais:<\/p>\n<ul>\n<li><strong>Reposit\u00f3rio de Chart<\/strong> \u2014 descri\u00e7\u00e3o e conjunto de parametriza\u00e7\u00f5es poss\u00edveis para o seu manifesto.\u00a0<\/li>\n<li><strong>Config<\/strong> \u2014 ou seja, valores que ser\u00e3o aplicados (texto, valores num\u00e9ricos, etc.).<\/li>\n<li><strong>Release<\/strong> re\u00fane os dois componentes principais, e juntos eles se tornam um Release. Os Releases podem ser versionados, atingindo assim uma organiza\u00e7\u00e3o do ciclo de vida: pequeno no momento da instala\u00e7\u00e3o e grande no momento de upgrade, downgrade ou rollback.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Arquitetura do Helm<\/h2>\n<p>\nNo diagrama, a arquitetura de alto n\u00edvel do Helm \u00e9 conceitualmente refletida.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/c5cf54890682a3d6ca7a45021b5006a1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVale lembrar que o Helm est\u00e1 relacionado ao Kubernetes. Portanto, n\u00e3o podemos prescindir de um cluster Kubernetes (ret\u00e2ngulo). O componente kube-apiserver est\u00e1 no mestre. Sem Helm, temos Kubeconfig. O Helm traz um pequeno bin\u00e1rio, se assim posso chamar, a ferramenta Helm CLI, que pode ser instalada no computador, laptop, mainframe \u2014 em qualquer lugar.<\/p>\n<p>Mas isso n\u00e3o \u00e9 suficiente. O Helm tem um componente servidor chamado Tiller. Ele representa os interesses do Helm dentro do cluster, sendo um aplicativo dentro do cluster Kubernetes, assim como qualquer outro.<\/p>\n<p>O pr\u00f3ximo componente \u00e9 o Reposit\u00f3rio de Chart \u2014 um reposit\u00f3rio com charts. Existe um reposit\u00f3rio oficial, e pode haver um reposit\u00f3rio privado da empresa ou do projeto.<\/p>\n<h3>Intera\u00e7\u00e3o<\/h3>\n<p>\nVamos considerar como os componentes da arquitetura interagem quando queremos instalar um aplicativo com o Helm.<\/p>\n<ul>\n<li>N\u00f3s dizemos <code>Helm install<\/code>, chamamos o reposit\u00f3rio (Reposit\u00f3rio de Chart) e obtemos o chart do Helm.<\/li>\n<\/ul>\n<p><\/p>\n<ul>\n<li>A ferramenta Helm (Helm CLI) interage com o Kubeconfig para descobrir a qual cluster se referir.\u00a0<\/li>\n<li>Obtidas essas informa\u00e7\u00f5es, a ferramenta se comunica com o Tiller, que est\u00e1 em nosso cluster, como se fosse um aplicativo.\u00a0<\/li>\n<li>O Tiller se dirige ao Kube-apiserver para realizar a\u00e7\u00f5es no Kubernetes, criando alguns objetos (servi\u00e7os, pods, r\u00e9plicas, segredos, etc.).<\/li>\n<\/ul>\n<p>\nEm seguida, vamos complicar o diagrama para ver o vetor de ataques ao qual toda a arquitetura do Helm pode estar sujeita. Depois, tentaremos proteg\u00ea-la.<\/p>\n<h3>Vetor de ataques<\/h3>\n<p>\nO primeiro ponto potencialmente fraco \u00e9 <strong>a API privilegiada<\/strong>\u2014<strong>usu\u00e1rio<\/strong>No \u00e2mbito do esquema, \u00e9 um hacker que obteve acesso administrativo ao Helm CLI.<\/p>\n<p><strong>Um usu\u00e1rio da API n\u00e3o privilegiado<\/strong> tamb\u00e9m pode representar um perigo se estiver por perto. Esse usu\u00e1rio ter\u00e1 outro contexto, por exemplo, ele pode estar fixado em um namespace do cluster nas configura\u00e7\u00f5es do Kubeconfig.<\/p>\n<p>O vetor de ataque mais interessante pode ser um processo que est\u00e1 dentro do cluster, perto do Tiller, e pode acess\u00e1-lo. Isso pode ser um servidor web ou um microsservi\u00e7o que v\u00ea o ambiente de rede do cluster.<\/p>\n<p>Uma variante ex\u00f3tica, mas em ascens\u00e3o, de ataque est\u00e1 relacionada ao Chart Repo. Um chart criado por um autor mal-intencionado pode conter recursos inseguros, e voc\u00ea o executar\u00e1, acreditando nele. Ou ele pode substituir o chart que voc\u00ea baixa do reposit\u00f3rio oficial e, por exemplo, criar um recurso na forma de pol\u00edticas e escalar seu acesso.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/2828046feb9ba8413a1b0e8741b4c354.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVamos tentar nos defender de ataques por todos esses quatro lados e descobrir onde est\u00e3o os problemas na arquitetura do Helm e onde, possivelmente, n\u00e3o est\u00e3o.<\/p>\n<p>Vamos ampliar o esquema, adicionar mais elementos, mas manter todos os componentes b\u00e1sicos.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/4110898e79619b8546408c668c48da0d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO Helm CLI se comunica com o Chart Repo, interage com o Kubeconfig, e a opera\u00e7\u00e3o \u00e9 transferida para o cluster no componente Tiller.<\/p>\n<p>O Tiller \u00e9 representado por dois objetos:<\/p>\n<ul>\n<li>O servi\u00e7o Tiller-deploy svc, que exp\u00f5e um certo servi\u00e7o;<\/li>\n<li>O pod Tiller-deploy (no esquema, em uma \u00fanica inst\u00e2ncia em uma r\u00e9plica), no qual toda a carga opera e que se comunica com o cluster.<\/li>\n<\/ul>\n<p>\nDiferentes protocolos e esquemas s\u00e3o usados para a intera\u00e7\u00e3o. Do ponto de vista de seguran\u00e7a, os mais interessantes para n\u00f3s s\u00e3o:<\/p>\n<ul>\n<li>O mecanismo pelo qual o Helm CLI acessa o chart repo: qual protocolo \u00e9 utilizado, existe autentica\u00e7\u00e3o e o que pode ser feito com isso.<\/li>\n<li>O protocolo pelo qual o Helm CLI, usando kubectl, se comunica com o Tiller. Este \u00e9 um servidor RPC instalado dentro do cluster.<\/li>\n<li>O pr\u00f3prio Tiller est\u00e1 acess\u00edvel para microsservi\u00e7os que est\u00e3o no cluster e interage com o Kube-apiserver.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/19e7e085567f3bbb49746e6402926bd6.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVamos discutir todas essas dire\u00e7\u00f5es em ordem.<\/p>\n<h2>RBAC<\/h2>\n<p><\/p>\n<blockquote><p>\u00c9 in\u00fatil falar sobre qualquer seguran\u00e7a do Helm ou de outro servi\u00e7o dentro do cluster se o RBAC n\u00e3o estiver ativado.<\/p><\/blockquote>\n<p>\nParece que essa n\u00e3o \u00e9 a recomenda\u00e7\u00e3o mais recente, mas estou certo de que muitos ainda n\u00e3o ativaram o RBAC mesmo em produ\u00e7\u00e3o, porque isso \u00e9 um grande trabalho e \u00e9 necess\u00e1rio ajustar muitas coisas. No entanto, eu encorajo a faz\u00ea-lo.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/37ee8aeb2b331b75ea5569c0b114a756.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/rbac.dev\/\">https:\/\/rbac.dev\/<\/a><\/noindex> \u2014 um site de advogado para RBAC. Ele re\u00fane uma enorme quantidade de materiais interessantes que ajudar\u00e3o a configurar o RBAC, mostrar\u00e3o por que ele \u00e9 bom e como viver com ele no ambiente de produ\u00e7\u00e3o.<\/p>\n<p>Vou tentar explicar como funciona o Tiller e o RBAC. O Tiller opera dentro do cluster sob uma conta de servi\u00e7o espec\u00edfica. Geralmente, se o RBAC n\u00e3o estiver configurado, ser\u00e1 um superusu\u00e1rio. Na configura\u00e7\u00e3o padr\u00e3o, o Tiller ser\u00e1 administrador. \u00c9 por isso que muitas vezes se diz que o Tiller \u00e9 um t\u00fanel SSH para seu cluster. Na verdade, \u00e9 assim, ent\u00e3o voc\u00ea pode usar uma conta de servi\u00e7o especializada em vez da Default Service Account no diagrama acima.<\/p>\n<p>Quando voc\u00ea inicializa o Helm, instalando-o pela primeira vez no servidor, pode definir uma conta de servi\u00e7o usando <code>--service-account<\/code>. Isso permitir\u00e1 usar um usu\u00e1rio com o m\u00ednimo conjunto necess\u00e1rio de permiss\u00f5es. No entanto, ser\u00e1 preciso criar uma \"guirlanda\": Role e RoleBinding.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/ec805cde756495cfd5c480ac40739c43.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nInfelizmente, o Helm n\u00e3o far\u00e1 isso por voc\u00ea. Voc\u00ea ou seu administrador do cluster Kubernetes precisam preparar previamente um conjunto de Role e RoleBinding para a conta de servi\u00e7o, para serem passados ao Helm.<\/p>\n<p>Surge a pergunta \u2013 qual \u00e9 a diferen\u00e7a entre Role e ClusterRole? A diferen\u00e7a \u00e9 que o ClusterRole atua para todos os namespaces, ao contr\u00e1rio das Role e RoleBinding comuns, que funcionam apenas para um namespace espec\u00edfico. \u00c9 poss\u00edvel configurar pol\u00edticas tanto para todo o cluster e todos os namespaces, quanto de forma personalizada para cada namespace individualmente.<\/p>\n<p>Vale mencionar que o RBAC tamb\u00e9m resolve outro grande problema. Muitos reclamam que o Helm, infelizmente, n\u00e3o \u00e9 multitenancy (n\u00e3o suporta multi-inquilinos). Se v\u00e1rias equipes utilizam o cluster e o Helm, \u00e9 praticamente imposs\u00edvel configurar pol\u00edticas e restringir o acesso dentro desse cluster, pois existe uma conta de servi\u00e7o sob a qual o Helm opera, e ele cria todos os recursos do cluster sob essa conta, o que muitas vezes \u00e9 muito inconveniente. Isso \u00e9 verdade \u2013 tanto o arquivo bin\u00e1rio em si, quanto o processo, <strong>O Helm Tiller n\u00e3o tem no\u00e7\u00e3o de multitenancy.<\/strong>.<\/p>\n<p>No entanto, h\u00e1 uma \u00f3tima maneira de executar o Tiller no cluster v\u00e1rias vezes. N\u00e3o h\u00e1 problemas com isso, o Tiller pode ser executado em cada namespace. Assim, voc\u00ea pode aproveitar o RBAC, o Kubeconfig como contexto, e limitar o acesso ao Helm espec\u00edfico.<\/p>\n<p>Isso se parecer\u00e1 com o seguinte.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/eae922c7b5e1422fb51667364ed79e0a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPor exemplo, h\u00e1 dois Kubeconfig com contexto para equipes diferentes (dois namespaces): Equipe X para a equipe de desenvolvimento e o cluster do administrador. O cluster do administrador possui um Tiller amplo, que est\u00e1 no namespace Kube-system, com uma service-account avan\u00e7ada. E um namespace separado para a equipe de desenvolvimento, que poder\u00e1 implantar seus servi\u00e7os em um namespace espec\u00edfico.<\/p>\n<p>Esse \u00e9 um m\u00e9todo vi\u00e1vel, Tiller n\u00e3o \u00e9 t\u00e3o exigente a ponto de impactar significativamente seu or\u00e7amento. \u00c9 uma das solu\u00e7\u00f5es r\u00e1pidas.<\/p>\n<blockquote><p>Sinta-se \u00e0 vontade para configurar o Tiller separadamente e fornecer Kubeconfig com contexto para a equipe, para um desenvolvedor espec\u00edfico ou para os ambientes: Dev, Staging, Production (\u00e9 duvidoso que tudo esteja em um \u00fanico cluster, no entanto, \u00e9 poss\u00edvel fazer assim).<\/p><\/blockquote>\n<p>\nDando continuidade \u00e0 nossa hist\u00f3ria, vamos mudar do RBAC e falar sobre ConfigMaps.<\/p>\n<h3>ConfigMaps<\/h3>\n<p>\nO Helm usa ConfigMaps como armazenamento de dados. Quando falamos sobre a arquitetura, n\u00e3o havia um banco de dados onde as informa\u00e7\u00f5es sobre releases, configura\u00e7\u00f5es, rollbacks, etc. fossem armazenadas. Para isso, s\u00e3o usados ConfigMaps.<\/p>\n<p>O principal problema com os ConfigMaps \u00e9 bem conhecido - eles n\u00e3o s\u00e3o seguros por princ\u00edpio, neles <strong>n\u00e3o \u00e9 poss\u00edvel armazenar dados sens\u00edveis<\/strong>. Refere-se a tudo que n\u00e3o deve ser exposto al\u00e9m do servi\u00e7o, como senhas. O m\u00e9todo mais nativo para o Helm atualmente \u00e9 a transi\u00e7\u00e3o do uso de ConfigMaps para segredos.<\/p>\n<p>Isso \u00e9 feito de forma muito simples. Voc\u00ea redefine a configura\u00e7\u00e3o do Tiller e indica que o armazenamento ser\u00e3o segredos. Ent\u00e3o, em cada deploy, voc\u00ea receber\u00e1 n\u00e3o um ConfigMap, mas sim um segredo.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/7fd12bfbed5c6c8111a5126c2ab9f853.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoc\u00ea pode argumentar que os pr\u00f3prios segredos s\u00e3o um conceito estranho e n\u00e3o s\u00e3o muito seguros. No entanto, \u00e9 importante entender que isso \u00e9 gerenciado pelos pr\u00f3prios desenvolvedores do Kubernetes. Desde a vers\u00e3o 1.10, ou seja, j\u00e1 faz um tempo, h\u00e1 a possibilidade, pelo menos em nuvens p\u00fablicas, de conectar um armazenamento adequado para armazenar segredos. A equipe agora est\u00e1 trabalhando para melhorar ainda mais o acesso aos segredos, a pods espec\u00edficas ou outras entidades.<\/p>\n<blockquote><p>O armazenamento do Helm deve ser melhorado para segredos, e estes devem ser protegidos de forma centralizada.<\/p><\/blockquote>\n<p>\nClaro, ainda haver\u00e1 <strong>um limite de armazenamento de dados de 1 MB<\/strong>. O Helm aqui utiliza o etcd como um armazenamento distribu\u00eddo para ConfigMaps. E l\u00e1 consideraram que esse era um chunk de dados apropriado para replica\u00e7\u00f5es, etc. H\u00e1 uma discuss\u00e3o interessante sobre isso no Reddit, recomendo que encontre essa leitura divertida para o fim de semana ou leia um resumo. <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/issues\/1413\">aqui<\/a><\/noindex>.<\/p>\n<h3>Reposit\u00f3rios de Charts<\/h3>\n<p>\nOs charts s\u00e3o socialmente vulner\u00e1veis e podem se tornar fonte de \"Man in the middle\", especialmente se uma solu\u00e7\u00e3o padr\u00e3o for utilizada. Em primeiro lugar, estamos falando de reposit\u00f3rios que s\u00e3o apresentados via HTTP.<\/p>\n<blockquote><p>Definitivamente, \u00e9 preciso expor o Helm Repo via HTTPS \u2014 essa \u00e9 a melhor op\u00e7\u00e3o e n\u00e3o custa muito.<\/p><\/blockquote>\n<p>\nPreste aten\u00e7\u00e3o em <strong>mecanismo de assinaturas de charts<\/strong>. A tecnologia \u00e9 incrivelmente simples. \u00c9 a mesma que voc\u00ea usa no GitHub, uma m\u00e1quina PGP comum com chaves p\u00fablicas e privadas. Configure e voc\u00ea ter\u00e1 certeza, tendo as chaves necess\u00e1rias e assinando tudo, de que este realmente \u00e9 seu chart.<\/p>\n<p>Al\u00e9m disso, <strong>O cliente Helm suporta TLS<\/strong> (n\u00e3o no sentido de HTTP do lado do servidor, mas mutual TLS). Voc\u00ea pode usar chaves de servidor e cliente para se comunicar. Vou ser honesto, n\u00e3o uso esse mecanismo por n\u00e3o gostar de certificados m\u00fatuos. Em princ\u00edpio, <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/chartmuseum\">chartmuseum<\/a><\/noindex> \u2014 a principal ferramenta para expor o Helm Repo para Helm 2 \u2014 tamb\u00e9m suporta autentica\u00e7\u00e3o b\u00e1sica. Voc\u00ea pode usar autentica\u00e7\u00e3o b\u00e1sica, se isso for mais conveniente e confort\u00e1vel.<\/p>\n<p>Ainda h\u00e1 um plugin <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/hayorov\/helm-gcs\">helm-gcs<\/a><\/noindex>, que permite hospedar Reposit\u00f3rios de Charts no Google Cloud Storage. Isso \u00e9 bastante conveniente, funciona muito bem e \u00e9 seguro o suficiente, pois utiliza todos os mecanismos descritos.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/6a72bfd96c7eb0e2fdd7bcbf128e6433.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe ativar HTTPS ou TLS, usar mTLS, adicionar autentica\u00e7\u00e3o b\u00e1sica para reduzir ainda mais os riscos, ter\u00e1 um canal de comunica\u00e7\u00e3o seguro entre o Helm CLI e o Chart Repo.<\/p>\n<h3>API gRPC<\/h3>\n<p>\nO pr\u00f3ximo passo \u00e9 muito importante \u2014 proteger o Tiller, que est\u00e1 no cluster e que, por um lado, \u00e9 um servidor e, por outro, acessa outros componentes e tenta se apresentar como algu\u00e9m.<\/p>\n<p>Como j\u00e1 disse, o Tiller \u00e9 um servi\u00e7o que exp\u00f5e gRPC, o cliente Helm se conecta a ele via gRPC. Por padr\u00e3o, naturalmente, o TLS est\u00e1 desligado. O porqu\u00ea disso \u00e9 uma quest\u00e3o discut\u00edvel, me parece ser para simplificar a configura\u00e7\u00e3o inicial.<\/p>\n<blockquote><p>Para produ\u00e7\u00e3o e at\u00e9 mesmo para staging, recomendo ativar TLS no gRPC.<\/p><\/blockquote>\n<p>\nNa minha opini\u00e3o, ao contr\u00e1rio do mTLS para gr\u00e1ficos, aqui isso \u00e9 apropriado e feito de forma muito simples \u2014 voc\u00ea gera a infraestrutura PQI, cria um certificado, inicia o Tiller e passa o certificado durante a inicializa\u00e7\u00e3o. Ap\u00f3s isso, voc\u00ea pode executar todos os comandos do Helm, apresentando-se com o certificado gerado e a chave privada.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/ed55b9a465ed1278b272c52c90b2b345.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAssim, voc\u00ea se proteger\u00e1 de todas as solicita\u00e7\u00f5es ao Tiller de fora do cluster.<\/p>\n<p>Agora, protegemos o canal de conex\u00e3o ao Tiller, j\u00e1 discutimos o RBAC e ajustamos as permiss\u00f5es do Kubernetes apiserver, reduzindo o dom\u00ednio com o qual ele pode interagir.<\/p>\n<h2>Helm Seguro<\/h2>\n<p>\nVamos olhar para o diagrama final. \u00c9 a mesma arquitetura com as mesmas setas.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/6672e254ad93b917f57794e1619a572e.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTodas as conex\u00f5es agora podem ser desenhadas em verde:<\/p>\n<ul>\n<li>para o Chart Repo, usamos TLS ou mTLS e autentica\u00e7\u00e3o b\u00e1sica;<\/li>\n<li>mTLS para o Tiller, que \u00e9 exposto como um servi\u00e7o gRPC com TLS, usando certificados;<\/li>\n<li>no cluster, usamos uma conta de servi\u00e7o especial com Role e RoleBinding.\u00a0<\/li>\n<\/ul>\n<p>\nN\u00f3s protegemos significativamente o cluster, mas algu\u00e9m s\u00e1bio disse:<\/p>\n<blockquote><p>\u00abA \u00fanica solu\u00e7\u00e3o absolutamente segura pode ser um computador desligado, que est\u00e1 dentro de uma caixa de concreto e \u00e9 guardado por soldados\u00bb.<\/p><\/blockquote>\n<p>\nExistem v\u00e1rias maneiras de manipula\u00e7\u00e3o de dados e encontrar novos vetores de ataque. No entanto, estou confiante de que essas recomenda\u00e7\u00f5es permitir\u00e3o implementar um padr\u00e3o industrial b\u00e1sico de seguran\u00e7a.<\/p>\n<h2>B\u00f4nus<\/h2>\n<p>\nEsta parte n\u00e3o se relaciona diretamente \u00e0 seguran\u00e7a, mas tamb\u00e9m ser\u00e1 \u00fatil. Vou mostrar algumas coisas interessantes que poucas pessoas conhecem. Por exemplo, como procurar gr\u00e1ficos \u2014 oficiais e n\u00e3o oficiais.<\/p>\n<p>No reposit\u00f3rio <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/charts\">github.com\/helm\/charts<\/a><\/noindex> atualmente h\u00e1 cerca de 300 gr\u00e1ficos e duas streams: stable e incubator. Quem contribui sabe muito bem como \u00e9 dif\u00edcil passar do incubator para o stable, e como \u00e9 f\u00e1cil sair do stable. No entanto, esse n\u00e3o \u00e9 o melhor instrumento para procurar gr\u00e1ficos para Prometheus e tudo o que voc\u00ea gosta, por uma simples raz\u00e3o \u2014 n\u00e3o \u00e9 um portal pr\u00e1tico para pesquisar pacotes.<\/p>\n<p>Mas existe um servi\u00e7o <noindex><a rel=\"nofollow\" href=\"https:\/\/hub.helm.sh\/\">hub.helm.sh<\/a><\/noindex>, com o qual \u00e9 muito mais f\u00e1cil encontrar gr\u00e1ficos. O mais importante \u00e9 que l\u00e1 h\u00e1 muito mais reposit\u00f3rios externos e quase 800 gr\u00e1ficos dispon\u00edveis. Al\u00e9m disso, voc\u00ea pode conectar seu pr\u00f3prio reposit\u00f3rio, se por algum motivo n\u00e3o quiser enviar seus gr\u00e1ficos para o stable.<\/p>\n<p>Experimente hub.helm.sh e vamos desenvolv\u00ea-lo juntos. Este servi\u00e7o est\u00e1 sob o projeto Helm, e voc\u00ea pode contribuir at\u00e9 mesmo na sua interface, se voc\u00ea \u00e9 um desenvolvedor front-end e deseja apenas melhorar a apar\u00eancia.<\/p>\n<p>Quero tamb\u00e9m chamar sua aten\u00e7\u00e3o para <strong>a integra\u00e7\u00e3o da API Open Service Broker<\/strong>. Parece complicado e confuso, mas resolve problemas com os quais todos se deparam. Vou explicar com um exemplo simples.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/3aeb7e0781e50a79b518f1056873f73a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTemos um cluster Kubernetes onde queremos rodar um aplicativo cl\u00e1ssico \u2014 WordPress. Normalmente, para plena funcionalidade, precisamos de um banco de dados. Existem muitas solu\u00e7\u00f5es diferentes, por exemplo, \u00e9 poss\u00edvel rodar seu pr\u00f3prio servi\u00e7o stateful. Isso n\u00e3o \u00e9 muito conveniente, mas muitos fazem assim.<\/p>\n<p>Outros, como n\u00f3s na Chainstack, utilizamos bancos de dados gerenciados, como MySQL ou PostgreSQL, para servidores. Assim, nossos bancos de dados est\u00e3o em algum lugar na nuvem.<\/p>\n<p>Mas surge um problema: \u00e9 necess\u00e1rio conectar nosso servi\u00e7o ao banco de dados, criar o flavor do banco de dados, passar as credenciais e gerenciar tudo isso. Geralmente, isso \u00e9 feito manualmente por um administrador de sistema ou um desenvolvedor. E n\u00e3o h\u00e1 problema algum quando h\u00e1 poucos aplicativos. Quando s\u00e3o muitos, \u00e9 preciso um mecanismo. Esse mecanismo existe \u2014 \u00e9 o Service Broker. Ele permite usar um plugin especial para o cluster de nuvem p\u00fablica e solicitar recursos ao provedor via Broker, como se fosse uma API. Isso pode ser feito com as ferramentas nativas do Kubernetes.<\/p>\n<p>\u00c9 muito simples. Por exemplo, podemos solicitar um Managed MySQL no Azure com o tier b\u00e1sico (isso pode ser configurado). Usando a API do Azure, o banco ser\u00e1 criado e preparado para uso. Voc\u00ea n\u00e3o precisar\u00e1 se envolver nisso, o plugin cuida disso. Por exemplo, o OSBA (plugin do Azure) retornar\u00e1 as credenciais ao servi\u00e7o, passando isso para o Helm. Voc\u00ea poder\u00e1 utilizar o WordPress com o MySQL na nuvem, sem se preocupar com bancos de dados gerenciados e sem se estressar com servi\u00e7os stateful internos.<\/p>\n<blockquote><p>Pode-se dizer que o Helm atua como uma cola, que de um lado permite implantar servi\u00e7os e do outro \u2014 consumir recursos dos provedores de nuvem.<\/p><\/blockquote>\n<p>\n\u00c9 poss\u00edvel escrever seu pr\u00f3prio plugin e utilizar toda essa hist\u00f3ria on-premise. Assim, voc\u00ea ter\u00e1 seu pr\u00f3prio plugin para o provedor de Cloud corporativo. Eu recomendo tentar essa abordagem, especialmente se voc\u00ea tem uma grande escala e deseja implantar rapidamente dev, staging ou toda a infraestrutura para uma funcionalidade. Isso facilitar\u00e1 a vida para suas opera\u00e7\u00f5es ou DevOps.<\/p>\n<p>Mais uma descoberta que j\u00e1 mencionei \u2014 \u00e9 o <strong>plugin helm-gcs<\/strong>, que permite usar Google-buckets (armazenamento de objetos) para armazenar charts do Helm.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/30888c4f9b5dba14b87ba1e29e0ebed7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nS\u00e3o necess\u00e1rias apenas quatro comandos para come\u00e7ar a utiliz\u00e1-lo:<\/p>\n<ol>\n<li>instalar o plugin;<\/li>\n<li>inicializ\u00e1-lo;<\/li>\n<li>definir o caminho para o bucket que est\u00e1 no gcp;<\/li>\n<li>publicar os charts de forma padr\u00e3o.<\/li>\n<\/ol>\n<p>\nA beleza disso \u00e9 que ser\u00e1 utilizado o m\u00e9todo nativo do gcp para autentica\u00e7\u00e3o. Voc\u00ea pode usar uma conta de servi\u00e7o, conta de desenvolvedor \u2014 o que quiser. Isso \u00e9 muito conveniente e n\u00e3o gera custos de opera\u00e7\u00e3o. Se voc\u00ea, assim como eu, defende a filosofia opsless, ser\u00e1 muito \u00fatil, especialmente para pequenas equipes.<\/p>\n<h2>Alternativas<\/h2>\n<p>\nO Helm n\u00e3o \u00e9 a \u00fanica solu\u00e7\u00e3o para gerenciamento de servi\u00e7os. Existem muitas quest\u00f5es sobre isso, talvez seja por isso que a terceira vers\u00e3o surgiu t\u00e3o rapidamente. Claro, existem alternativas.<\/p>\n<p>Podem ser solu\u00e7\u00f5es especializadas, como Ksonnet ou Metaparticle. Voc\u00ea pode usar suas ferramentas cl\u00e1ssicas de gerenciamento de infraestrutura (Ansible, Terraform, Chef, etc.) para os mesmos fins que mencionei.<\/p>\n<p>Finalmente, h\u00e1 uma solu\u00e7\u00e3o <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/operator-framework\">Operator Framework<\/a><\/noindex>, cuja popularidade est\u00e1 crescendo.<\/p>\n<blockquote><p>Operator Framework \u00e9 a principal alternativa ao Helm, que merece aten\u00e7\u00e3o.<\/p><\/blockquote>\n<p>\n\u00c9 mais nativo para CNCF e Kubernetes, <strong>mas a barreira de entrada \u00e9 muito maior<\/strong>, requer mais programa\u00e7\u00e3o e menos descri\u00e7\u00e3o de manifestos.<\/p>\n<p>Existem v\u00e1rios addons, como Draft, Scaffold. Eles facilitam muito a vida, por exemplo, para os desenvolvedores, simplificando o ciclo de envio e execu\u00e7\u00e3o do Helm para o deployment de um ambiente de teste. Eu os chamaria de expandidores de capacidades.<\/p>\n<p>Aqui est\u00e1 um gr\u00e1fico claro sobre onde cada coisa est\u00e1.<\/p>\n<p><img decoding=\"async\" alt=\"Seguran\u00e7a do Helm\" src=\"\/wp-content\/uploads\/2019\/08\/81a8236c975d5e1649acaaa7989c27ba.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNo eixo horizontal est\u00e1 o n\u00edvel de controle pessoal que voc\u00ea tem sobre o que est\u00e1 acontecendo, e no eixo vertical est\u00e1 o n\u00edvel de natividade do Kubernetes. A vers\u00e3o 2 do Helm est\u00e1 mais ou menos no meio. A vers\u00e3o 3 n\u00e3o trouxe uma grande diferen\u00e7a, mas tanto o controle quanto o n\u00edvel de natividade foram aprimorados. As solu\u00e7\u00f5es de n\u00edvel Ksonnet ainda ficam atr\u00e1s at\u00e9 mesmo do Helm 2. No entanto, vale a pena dar uma olhada nelas para saber o que mais existe neste mundo. Claro, seu gerenciador de configura\u00e7\u00e3o estar\u00e1 sob seu controle, mas n\u00e3o \u00e9 absolutamente nativo para Kubernetes.<\/p>\n<p>O Operator Framework \u00e9 absolutamente nativo para Kubernetes e permite gerenci\u00e1-lo de uma forma muito mais elegante e minuciosa (mas lembremos do n\u00edvel de entrada). Provavelmente, \u00e9 mais adequado para aplica\u00e7\u00f5es especializadas e para criar ger\u00eancia para elas, em vez de um grande combinado para empacotar uma enorme quantidade de aplica\u00e7\u00f5es com o Helm.<\/p>\n<p>Os expandidores apenas melhoram um pouco o controle, complementam o fluxo de trabalho ou cortam arestas dos pipelines de CI\/CD.<\/p>\n<h2>O futuro do Helm<\/h2>\n<p>\nA boa not\u00edcia \u00e9 que o Helm 3 est\u00e1 chegando. J\u00e1 foi lan\u00e7ada a vers\u00e3o alfa do Helm 3.0.0-alpha.2, que pode ser testada. Est\u00e1 bastante est\u00e1vel, mas a funcionalidade ainda \u00e9 limitada.<\/p>\n<p>Por que o Helm 3 \u00e9 necess\u00e1rio? Em primeiro lugar, \u00e9 sobre <strong>o desaparecimento do Tiller<\/strong>, como componente. Isso, como voc\u00ea j\u00e1 deve entender, \u00e9 um grande passo \u00e0 frente, pois do ponto de vista de seguran\u00e7a da arquitetura tudo fica mais simples.<\/p>\n<p>Quando o Helm 2 foi criado, isso foi durante os tempos do Kubernetes 1.8 ou at\u00e9 antes, muitas concep\u00e7\u00f5es eram imaturas. Por exemplo, a concep\u00e7\u00e3o de CRD est\u00e1 sendo ativamente implementada agora, e o Helm vai <strong>usar CRD<\/strong>, para armazenar estruturas. Ser\u00e1 poss\u00edvel usar apenas o cliente e n\u00e3o precisar manter a parte do servidor. Assim, ser\u00e1 poss\u00edvel utilizar comandos nativos do Kubernetes para trabalhar com estruturas e recursos. Isso \u00e9 um enorme passo \u00e0 frente.<\/p>\n<p>Haver\u00e1 <strong>suporte a reposit\u00f3rios nativos OCI<\/strong> (Open Container Initiative). Esta \u00e9 uma grande iniciativa, e para o Helm, ela \u00e9 interessante principalmente para hospedar seus charts. Chega ao ponto de que, por exemplo, o Docker Hub suporta muitos padr\u00f5es OCI. Eu n\u00e3o estou prevendo, mas \u00e9 poss\u00edvel que os provedores cl\u00e1ssicos de reposit\u00f3rios Docker comecem a permitir que voc\u00ea hospede seus charts do Helm.<\/p>\n<p>Uma hist\u00f3ria pol\u00eamica para mim \u00e9 a <strong>suporte ao Lua<\/strong>, como engine de templating para escrever scripts. Eu n\u00e3o sou um grande f\u00e3 de Lua, mas isso ser\u00e1 uma op\u00e7\u00e3o totalmente opcional. Eu verifiquei tr\u00eas vezes \u2014 o uso do Lua n\u00e3o ser\u00e1 obrigat\u00f3rio. Portanto, quem quiser poder\u00e1 usar Lua, quem gosta de Go \u2014 junte-se ao nosso grande grupo e use o go-tmpl para isso.<\/p>\n<p>Finalmente, o que eu realmente sentia falta era da <strong>apari\u00e7\u00e3o de esquemas e valida\u00e7\u00e3o de tipos de dados<\/strong>. N\u00e3o haver\u00e1 mais problemas com int ou string, n\u00e3o ser\u00e1 necess\u00e1rio colocar zero entre aspas duplas. Haver\u00e1 um esquema JSONS, que permitir\u00e1 descrever isso explicitamente para os values.<\/p>\n<p>A modelo baseado em eventos <strong>ser\u00e1 fortemente reformulada.<\/strong>J\u00e1 est\u00e1 conceitualmente descrita. Veja a branch do Helm 3 e veja quantos eventos, hooks e outros foram adicionados, o que simplificar\u00e1 muito e, por outro lado, aumentar\u00e1 o controle sobre os processos de deployment e rea\u00e7\u00f5es a eles.<\/p>\n<p>O Helm 3 ser\u00e1 mais simples, seguro e interessante n\u00e3o porque n\u00e3o gostamos do Helm 2, mas porque o Kubernetes est\u00e1 se tornando mais avan\u00e7ado. Assim, o Helm poder\u00e1 utilizar as inova\u00e7\u00f5es do Kubernetes e criar excelentes gerentes para o Kubernetes.<\/p>\n<blockquote><p>Outra boa not\u00edcia \u00e9 que <noindex><a rel=\"nofollow\" href=\"https:\/\/devopsconf.io\/moscow\/2019\">DevOpsConf<\/a><\/noindex> Alexandre Khayev falar\u00e1 sobre <noindex><a rel=\"nofollow\" href=\"https:\/\/devopsconf.io\/moscow\/2019\/abstracts\/5564\">se os containers podem ser seguros?<\/a><\/noindex> Lembramos que a confer\u00eancia sobre a integra\u00e7\u00e3o dos processos de desenvolvimento, teste e opera\u00e7\u00e3o ocorrer\u00e1 em Moscovo <strong>nos dias 30 de setembro e 1 de outubro.<\/strong>At\u00e9 20 de agosto ainda \u00e9 poss\u00edvel <noindex><a rel=\"nofollow\" href=\"https:\/\/conf.ontico.ru\/lectures\/propose\/?conference=dc2019-moscow\">submeter uma proposta<\/a><\/noindex> e compartilhar sua experi\u00eancia na solu\u00e7\u00e3o <noindex><a rel=\"nofollow\" href=\"https:\/\/devopsconf.io\/moscow\/2019\/articles\/917\">de um dos muitos<\/a><\/noindex> desafios da abordagem DevOps.<\/p>\n<p>Acompanhe os checkpoints da confer\u00eancia e as novidades no <noindex><a rel=\"nofollow\" href=\"http:\/\/eepurl.com\/bN_0E1\">newsletter<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/DevOpsConfChannel\">canal do telegram.<\/a><\/noindex>.<\/p><\/blockquote>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/oleg-bunin\/blog\/462665\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0421\u0443\u0442\u044c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430 \u043e \u0441\u0430\u043c\u043e\u043c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u043c \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0435 \u0434\u043b\u044f Kubernetes \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u043b\u043e \u0431\u044b \u0438\u0437\u043e\u0431\u0440\u0430\u0437\u0438\u0442\u044c \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u044d\u043c\u043e\u0434\u0436\u0438: \u043a\u043e\u0440\u043e\u0431\u043a\u0430 \u2014 \u044d\u0442\u043e Helm (\u044d\u0442\u043e \u0441\u0430\u043c\u043e\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435, \u0447\u0442\u043e \u0435\u0441\u0442\u044c \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u043c \u0440\u0435\u043b\u0438\u0437\u0435 Emoji); \u0437\u0430\u043c\u043e\u043a \u2014 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c; \u0447\u0435\u043b\u043e\u0432\u0435\u0447\u0435\u043a \u2014 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u044b. \u041d\u0430 \u0441\u0430\u043c\u043e\u043c \u0436\u0435 \u0434\u0435\u043b\u0435, \u0432\u0441\u0435 \u0431\u0443\u0434\u0435\u0442 \u043d\u0435\u043c\u043d\u043e\u0436\u0435\u0447\u043a\u043e \u0441\u043b\u043e\u0436\u043d\u0435\u0435, \u0438 \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u043f\u043e\u043b\u043e\u043d \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0435\u0439 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0441\u0434\u0435\u043b\u0430\u0442\u044c Helm \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u044b\u043c. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27661,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36918","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0421\u0443\u0442\u044c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430 \u043e \u0441\u0430\u043c\u043e\u043c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u043c \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0435 \u0434\u043b\u044f Kubernetes \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u043b\u043e \u0431\u044b \u0438\u0437\u043e\u0431\u0440\u0430\u0437\u0438\u0442\u044c \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u044d\u043c\u043e\u0434\u0436\u0438: \u043a\u043e\u0440\u043e\u0431\u043a\u0430 \u2014 \u044d\u0442\u043e Helm (\u044d\u0442\u043e \u0441\u0430\u043c\u043e\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435, \u0447\u0442\u043e \u0435\u0441\u0442\u044c \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u043c \u0440\u0435\u043b\u0438\u0437\u0435 Emoji);.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/bezopasnost-helm\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0411\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c Helm | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0421\u0443\u0442\u044c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430 \u043e \u0441\u0430\u043c\u043e\u043c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u043c \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0435 \u0434\u043b\u044f Kubernetes \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u043b\u043e \u0431\u044b \u0438\u0437\u043e\u0431\u0440\u0430\u0437\u0438\u0442\u044c \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u044d\u043c\u043e\u0434\u0436\u0438: \u043a\u043e\u0440\u043e\u0431\u043a\u0430 \u2014 \u044d\u0442\u043e Helm (\u044d\u0442\u043e \u0441\u0430\u043c\u043e\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435, \u0447\u0442\u043e \u0435\u0441\u0442\u044c \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u043c \u0440\u0435\u043b\u0438\u0437\u0435 Emoji);.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/bezopasnost-helm\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:14:43+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:14:43+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Seguran\u00e7a do Helm | ProHoster","description":"A ess\u00eancia da apresenta\u00e7\u00e3o sobre o gerenciador de pacotes mais popular para Kubernetes poderia ser ilustrada com emojis: a caixa representa o Helm (\u00e9 a mais adequada que existe na \u00faltima vers\u00e3o do Emoji);","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/bezopasnost-helm","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\u0411\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u044c Helm | ProHoster","og:description":"\u0421\u0443\u0442\u044c \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430 \u043e \u0441\u0430\u043c\u043e\u043c \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u043e\u043c \u043f\u0430\u043a\u0435\u0442\u043d\u043e\u043c \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440\u0435 \u0434\u043b\u044f Kubernetes \u043c\u043e\u0436\u043d\u043e \u0431\u044b\u043b\u043e \u0431\u044b \u0438\u0437\u043e\u0431\u0440\u0430\u0437\u0438\u0442\u044c \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u044d\u043c\u043e\u0434\u0436\u0438: \u043a\u043e\u0440\u043e\u0431\u043a\u0430 \u2014 \u044d\u0442\u043e Helm (\u044d\u0442\u043e \u0441\u0430\u043c\u043e\u0435 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0435\u0435, \u0447\u0442\u043e \u0435\u0441\u0442\u044c \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0435\u043c \u0440\u0435\u043b\u0438\u0437\u0435 Emoji);.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/bezopasnost-helm","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:14:43+00:00","article:modified_time":"2019-10-31T19:14:43+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36918","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-22 05:19:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:36:25","updated":"2026-01-22 05:19:19","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\/36918","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=36918"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/36918\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/27661"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=36918"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=36918"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=36918"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}