Segurança do leme

A essência da história sobre o gerenciador de pacotes mais popular para Kubernetes pode ser retratada usando um emoji:

• a caixa é Helm (que é a coisa mais próxima do lançamento mais recente do Emoji);
• fechadura - segurança;
• o homenzinho é a solução para o problema.

Na verdade, tudo será um pouco mais complicado, e a história está repleta de detalhes técnicos sobre Como tornar o Helm seguro.

• Resumidamente o que é Helm caso você não saiba ou tenha esquecido. Que problemas resolve e onde está localizado no ecossistema.
• Vejamos a arquitetura Helm. Nenhuma conversa sobre segurança e como tornar uma ferramenta ou solução mais segura está completa sem a compreensão da arquitetura do componente.
• Vamos discutir os componentes do Helm.
• A questão mais urgente é o futuro - a nova versão do Helm 3. 

Tudo neste artigo se aplica ao Helm 2. Esta versão está atualmente em produção e é provavelmente a que você está usando atualmente, e é a versão que contém os riscos de segurança.

Sobre o palestrante: Alexander Khayorov (allexx) vem se desenvolvendo há 10 anos, ajudando a melhorar o conteúdo Moscou Python Conf++ e se juntou ao comitê Cimeira do Leme. Agora ele trabalha na Chainstack como líder de desenvolvimento - um híbrido entre um gerente de desenvolvimento e uma pessoa responsável por entregar as versões finais. Ou seja, está localizado no campo de batalha, onde tudo acontece desde a criação de um produto até o seu funcionamento.

Chainstack é uma startup pequena e em crescimento ativo cuja missão é permitir que os clientes esqueçam a infraestrutura e as complexidades da operação de aplicações descentralizadas; a equipe de desenvolvimento está localizada em Cingapura. Não peça ao Chainstack para vender ou comprar criptomoedas, mas ofereça-se para falar sobre estruturas de blockchain empresariais, e eles responderão com prazer.

Capacete

Este é um gerenciador de pacotes (gráfico) para Kubernetes. A maneira mais intuitiva e universal de trazer aplicações para um cluster Kubernetes.

Estamos, é claro, falando de uma abordagem mais estrutural e industrial do que criar seus próprios manifestos YAML e escrever pequenos utilitários.

Helm é o melhor que está disponível e popular atualmente.

Por que Helm? Principalmente porque é apoiado pelo CNCF. Cloud Native é uma grande organização e é a controladora de projetos Kubernetes, etcd, Fluentd e outros.

Outro fato importante é que Helm é um projeto muito popular. Quando comecei a falar sobre como tornar o Helm seguro em janeiro de 2019, o projeto tinha mil estrelas no GitHub. Em maio eram 12 mil.

Muitas pessoas estão interessadas no Helm, então mesmo que você ainda não o use, você se beneficiará ao saber sobre sua segurança. A segurança é importante.

A equipe principal do Helm é suportada pelo Microsoft Azure e, portanto, é um projeto bastante estável, diferente de muitos outros. O lançamento do Helm 3 Alpha 2 em meados de julho indica que há muitas pessoas trabalhando no projeto e que têm desejo e energia para desenvolver e melhorar o Helm.

Helm resolve vários problemas básicos de gerenciamento de aplicativos no Kubernetes.

• Embalagem de aplicativos. Mesmo um aplicativo como “Hello, World” no WordPress já consiste em vários serviços e você deseja empacotá-los juntos.
• Gerenciando a complexidade associada ao gerenciamento desses aplicativos.
• Um ciclo de vida que não termina após a instalação ou implantação do aplicativo. Ele continua vivo, precisa ser atualizado, e o Helm ajuda nisso e tenta trazer as medidas e políticas certas para isso.

Ensacamento está organizado de forma clara: existem metadados em total conformidade com o trabalho de um gerenciador de pacotes regular para Linux, Windows ou MacOS. Ou seja, um repositório, dependências de vários pacotes, meta informações para aplicações, configurações, recursos de configuração, indexação de informações, etc. O Helm permite obter e usar tudo isso para aplicações.

Gerenciamento de Complexidade. Se você tiver muitas aplicações do mesmo tipo, será necessária parametrização. Os modelos vêm daí, mas para evitar ter que criar sua própria maneira de criar modelos, você pode usar o que o Helm oferece pronto para uso.

Gerenciamento do ciclo de vida de aplicativos - na minha opinião, esta é a questão mais interessante e não resolvida. É por isso que vim para Helm naquela época. Precisávamos ficar de olho no ciclo de vida do aplicativo e queríamos migrar nossos ciclos de CI/CD e de aplicativo para esse paradigma.

Helm permite que você:

• gerenciar implantações, introduz o conceito de configuração e revisão;
• realizar a reversão com sucesso;
• use ganchos para diferentes eventos;
• adicione verificações adicionais de aplicativos e responda aos seus resultados.

Além disso Helm tem “baterias” - uma grande quantidade de coisas saborosas que podem ser incluídas na forma de plugins, simplificando sua vida. Os plugins podem ser escritos de forma independente, são bastante isolados e não requerem uma arquitetura harmoniosa. Se você quiser implementar algo, recomendo fazê-lo como um plugin e, possivelmente, incluí-lo no upstream.

Helm é baseado em três conceitos principais:

• Repositório de gráficos — descrição e conjunto de parametrizações possíveis para seu manifesto. 
• Configuração —ou seja, os valores que serão aplicados (texto, valores numéricos, etc.).
• Solte coleta os dois componentes superiores e juntos eles se transformam em Release. As versões podem ser versionadas, alcançando assim um ciclo de vida organizado: pequeno no momento da instalação e grande no momento da atualização, downgrade ou reversão.

Arquitetura do leme

O diagrama descreve conceitualmente a arquitetura de alto nível do Helm.

Deixe-me lembrá-lo de que Helm é algo relacionado ao Kubernetes. Portanto, não podemos prescindir de um cluster Kubernetes (retângulo). O componente kube-apiserver reside no mestre. Sem Helm, temos o Kubeconfig. Helm traz um pequeno binário, se você pode chamá-lo assim, utilitário Helm CLI, que é instalado em um computador, laptop, mainframe - em qualquer coisa.

Mas isto não é o suficiente. Helm possui um componente de servidor chamado Tiller. Representa os interesses do Helm dentro do cluster; é uma aplicação dentro do cluster Kubernetes, como qualquer outra.

O próximo componente do Chart Repo é um repositório com gráficos. Existe um repositório oficial, podendo haver um repositório privado de uma empresa ou projeto.

Interação

Vejamos como os componentes da arquitetura interagem quando queremos instalar um aplicativo usando Helm.

• Nós falamos Helm install, acesse o repositório (Chart Repo) e obtenha um gráfico do Helm.

• O utilitário Helm (Helm CLI) interage com o Kubeconfig para descobrir qual cluster entrar em contato. 
• Tendo recebido essas informações, o utilitário refere-se ao Tiller, que está localizado em nosso cluster, como um aplicativo. 
• O Tiller chama o Kube-apiserver para realizar ações no Kubernetes, criar alguns objetos (serviços, pods, réplicas, segredos, etc.).

A seguir, complicaremos o diagrama para ver o vetor de ataque ao qual toda a arquitetura Helm como um todo pode ser exposta. E então tentaremos protegê-la.

Vetor de ataque

O primeiro ponto fraco potencial é API privilegiada-usuário. Como parte do esquema, trata-se de um hacker que obteve acesso de administrador ao Helm CLI.

Usuário de API sem privilégios também pode representar um perigo se estiver em algum lugar próximo. Esse usuário terá um contexto diferente, por exemplo, ele pode ser fixado em um namespace de cluster nas configurações do Kubeconfig.

O vetor de ataque mais interessante pode ser um processo localizado dentro de um cluster em algum lugar próximo ao Tiller e que possa acessá-lo. Pode ser um servidor web ou microsserviço que vê o ambiente de rede do cluster.

Uma variante de ataque exótica, mas cada vez mais popular, envolve o Chart Repo. Um gráfico criado por um autor sem escrúpulos pode conter recursos inseguros, e você o completará confiando nele. Ou pode substituir o gráfico que você baixa do repositório oficial e, por exemplo, criar um recurso em forma de políticas e escalar seu acesso.

Vamos tentar evitar ataques de todos esses quatro lados e descobrir onde há problemas na arquitetura Helm e onde talvez não haja.

Vamos ampliar o diagrama, adicionar mais elementos, mas manter todos os componentes básicos.

A CLI do Helm se comunica com o Chart Repo, interage com o Kubeconfig e o trabalho é transferido do cluster para o componente Tiller.

O Tiller é representado por dois objetos:

• Tiller-deploy svc, que expõe um determinado serviço;
• Pod Tiller-deploy (no diagrama em uma única cópia em uma réplica), no qual é executada toda a carga, que acessa o cluster.

Diferentes protocolos e esquemas são usados ​​para interação. Do ponto de vista da segurança, estamos mais interessados ​​em:

• O mecanismo pelo qual a CLI do Helm acessa o repositório de gráficos: qual protocolo, existe autenticação e o que pode ser feito com ele.
• O protocolo pelo qual Helm CLI, usando kubectl, se comunica com o Tiller. Este é um servidor RPC instalado dentro do cluster.
• O próprio Tiller é acessível a microsserviços que residem no cluster e interage com o Kube-apiserver.

Vamos discutir todas essas áreas em ordem.

RBAC

Não faz sentido falar sobre qualquer segurança para o Helm ou qualquer outro serviço dentro do cluster, a menos que o RBAC esteja habilitado.

Parece que essa não é a recomendação mais recente, mas tenho certeza que muita gente ainda não habilitou o RBAC nem em produção, porque é muito barulho e muita coisa precisa ser configurada. No entanto, encorajo você a fazer isso.

https://rbac.dev/ — advogado do site da RBAC. Ele contém uma enorme quantidade de materiais interessantes que ajudarão você a configurar o RBAC, mostrar por que ele é bom e como basicamente conviver com ele na produção.

Tentarei explicar como funcionam o Tiller e o RBAC. O Tiller funciona dentro do cluster sob uma determinada conta de serviço. Normalmente, se o RBAC não estiver configurado, este será o superusuário. Na configuração básica, o Tiller será um administrador. É por isso que se costuma dizer que o Tiller é um túnel SSH para o seu cluster. Na verdade, isso é verdade, então você pode usar uma conta de serviço dedicada separada em vez da conta de serviço padrão no diagrama acima.

Ao inicializar o Helm e instalá-lo no servidor pela primeira vez, você pode definir a conta de serviço usando --service-account. Isso permitirá que você use um usuário com o conjunto mínimo de direitos exigido. É verdade que você terá que criar uma “guirlanda”: ​​Role e RoleBinding.

Infelizmente, Helm não fará isso por você. Você ou o administrador do cluster Kubernetes precisam preparar um conjunto de funções e RoleBindings para a conta de serviço com antecedência para passar no Helm.

Surge a pergunta - qual é a diferença entre Role e ClusterRole? A diferença é que ClusterRole funciona para todos os namespaces, ao contrário de Roles e RoleBindings regulares, que funcionam apenas para um namespace especializado. Você pode configurar políticas para todo o cluster e todos os namespaces ou personalizá-las para cada namespace individualmente.

Vale ressaltar que o RBAC resolve outro grande problema. Muitas pessoas reclamam que o Helm, infelizmente, não é multitenancy (não suporta multitenancy). Se várias equipes consumirem um cluster e usarem o Helm, será basicamente impossível configurar políticas e limitar seu acesso dentro deste cluster, porque há uma determinada conta de serviço sob a qual o Helm é executado e cria todos os recursos no cluster a partir dela. , o que às vezes é muito inconveniente. Isto é verdade - como o próprio arquivo binário, como o processo, Helm Tiller não tem conceito de multilocação.

No entanto, existe uma ótima maneira que permite executar o Tiller várias vezes em um cluster. Não há problema com isso, o Tiller pode ser iniciado em qualquer namespace. Assim, você pode usar RBAC, Kubeconfig como contexto e limitar o acesso a um Helm especial.

Isso parecerá assim.

Por exemplo, existem dois Kubeconfigs com contexto para equipes diferentes (dois namespaces): X Team para a equipe de desenvolvimento e o cluster de administração. O cluster de administração tem seu próprio Tiller amplo, localizado no namespace do sistema Kube, uma conta de serviço correspondentemente avançada. E um namespace separado para a equipe de desenvolvimento, eles poderão implantar seus serviços em um namespace especial.

Esta é uma abordagem viável, o Tiller não tem tanta fome de energia a ponto de afetar muito o seu orçamento. Esta é uma das soluções rápidas.

Fique à vontade para configurar o Tiller separadamente e fornecer ao Kubeconfig contexto para a equipe, para um desenvolvedor específico ou para o ambiente: Dev, Staging, Production (é duvidoso que tudo fique no mesmo cluster, porém, isso pode ser feito).

Continuando nossa história, vamos mudar do RBAC e falar sobre ConfigMaps.

ConfigMaps

Helm usa ConfigMaps como armazenamento de dados. Quando falamos sobre arquitetura, não havia banco de dados em lugar nenhum que pudesse armazenar informações sobre releases, configurações, rollbacks, etc. O ConfigMaps é usado para isso.

O principal problema dos ConfigMaps é conhecido - eles não são seguros em princípio; é impossível armazenar dados confidenciais. Estamos falando de tudo que não deve ir além do serviço, por exemplo, senhas. A maneira mais nativa do Helm agora é mudar do uso de ConfigMaps para segredos.

Isso é feito de forma muito simples. Substitua a configuração do Tiller e especifique que o armazenamento será secreto. Então, para cada implantação, você não receberá um ConfigMap, mas um segredo.

Você poderia argumentar que os próprios segredos são um conceito estranho e não muito seguro. No entanto, vale a pena entender que os próprios desenvolvedores do Kubernetes estão fazendo isso. A partir da versão 1.10, ou seja, Já há algum tempo é possível, pelo menos em nuvens públicas, conectar o armazenamento correto para armazenar segredos. A equipe agora está trabalhando em maneiras de distribuir melhor o acesso a segredos, pods individuais ou outras entidades.

É melhor transferir o Storage Helm para segredos, e eles, por sua vez, são protegidos centralmente.

Claro que permanecerá limite de armazenamento de dados de 1 MB. Helm aqui usa etcd como armazenamento distribuído para ConfigMaps. E lá eles consideraram que este era um bloco de dados adequado para replicação, etc. Há uma discussão interessante sobre isso no Reddit, recomendo encontrar esta leitura engraçada para o fim de semana ou ler o trecho aqui.

Repositórios de gráficos

Os gráficos são os mais vulneráveis ​​socialmente e podem se tornar uma fonte de “homem no meio”, especialmente se você usar uma solução de estoque. Em primeiro lugar, estamos falando de repositórios expostos via HTTP.

Definitivamente, você precisa expor o Helm Repo por HTTPS - esta é a melhor opção e é barata.

Note-se a mecanismo de assinatura de gráfico. A tecnologia é simples como o inferno. É a mesma coisa que você usa no GitHub, uma máquina PGP normal com chaves públicas e privadas. Configure e tenha certeza, tendo as chaves necessárias e assinando tudo, que este é realmente o seu gráfico.

Além disso, O cliente Helm suporta TLS (não no sentido HTTP do lado do servidor, mas no TLS mútuo). Você pode usar chaves de servidor e cliente para se comunicar. Para ser sincero, não uso esse mecanismo porque não gosto de certificados mútuos. Basicamente, museu gráfico - a principal ferramenta para configurar o Helm Repo para Helm 2 - também suporta autenticação básica. Você pode usar a autenticação básica se for mais conveniente e silencioso.

Também existe um plugin helm-gcs, que permite hospedar Chart Repos no Google Cloud Storage. Isto é bastante cómodo, funciona muito bem e é bastante seguro, porque todos os mecanismos descritos são reciclados.

Se você habilitar HTTPS ou TLS, usar mTLS e habilitar a autenticação básica para reduzir ainda mais os riscos, você obterá um canal de comunicação seguro com Helm CLI e Chart Repo.

API gRPC

O próximo passo é muito importante - proteger o Tiller, que está localizado no cluster e é, por um lado, um servidor, por outro lado, ele próprio acessa outros componentes e tenta se passar por alguém.

Como já disse, o Tiller é um serviço que expõe o gRPC, o cliente Helm chega até ele via gRPC. Por padrão, é claro, o TLS está desabilitado. Por que isso foi feito é uma questão discutível, parece-me simplificar a configuração no início.

Para produção e até mesmo teste, recomendo habilitar o TLS no gRPC.

Na minha opinião, ao contrário do mTLS para gráficos, isso é apropriado aqui e é feito de forma muito simples - gerar uma infraestrutura PQI, criar um certificado, iniciar o Tiller, transferir o certificado durante a inicialização. Depois disso, você pode executar todos os comandos do Helm, apresentando-se com o certificado gerado e a chave privada.

Dessa forma, você se protegerá de todas as solicitações ao Tiller de fora do cluster.

Assim, asseguramos o canal de conexão ao Tiller, já discutimos o RBAC e ajustamos os direitos do apiserver Kubernetes, reduzindo o domínio com o qual ele pode interagir.

Elmo Protegido

Vejamos o diagrama final. É a mesma arquitetura com as mesmas setas.

Todas as conexões agora podem ser desenhadas com segurança em verde:

• para Chart Repo usamos TLS ou mTLS e autenticação básica;
• mTLS para Tiller, e é exposto como um serviço gRPC com TLS, usamos certificados;
• o cluster usa uma conta de serviço especial com Role e RoleBinding. 

Protegemos significativamente o cluster, mas alguém inteligente disse:

“Só pode haver uma solução absolutamente segura: um computador desligado, localizado em uma caixa de concreto e guardado por soldados.”

Existem diferentes maneiras de manipular dados e encontrar novos vetores de ataque. No entanto, estou confiante de que estas recomendações atingirão um padrão básico de segurança na indústria.

bônus

Esta parte não está diretamente relacionada à segurança, mas também será útil. Vou mostrar algumas coisas interessantes que poucas pessoas conhecem. Por exemplo, como pesquisar gráficos - oficiais e não oficiais.

No repositório github.com/helm/charts Agora são cerca de 300 prontuários e dois fluxos: estável e incubadora. Qualquer pessoa que contribua sabe perfeitamente como é difícil passar da incubadora para o estábulo e como é fácil sair voando do estábulo. No entanto, esta não é a melhor ferramenta para pesquisar gráficos do Prometheus e tudo o que você quiser, por uma razão simples - não é um portal onde você pode pesquisar pacotes de maneira conveniente.

Mas há um serviço hub.helm.sh, o que torna muito mais conveniente encontrar gráficos. Mais importante ainda, existem muito mais repositórios externos e quase 800 encantos disponíveis. Além disso, você pode conectar seu repositório se por algum motivo não quiser enviar seus gráficos para o stable.

Experimente hub.helm.sh e vamos desenvolvê-lo juntos. Este serviço está no projeto Helm, e você pode até contribuir com sua UI se for um desenvolvedor front-end e quiser apenas melhorar a aparência.

Gostaria também de chamar a sua atenção para Integração da API do Open Service Broker. Parece complicado e pouco claro, mas resolve problemas que todos enfrentam. Deixe-me explicar com um exemplo simples.

Existe um cluster Kubernetes no qual queremos executar um aplicativo clássico - WordPress. Geralmente, um banco de dados é necessário para funcionalidade completa. Existem muitas soluções diferentes, por exemplo, você pode lançar seu próprio serviço statefull. Isso não é muito conveniente, mas muitas pessoas fazem isso.

Outros, como nós da Chainstack, usam bancos de dados gerenciados como MySQL ou PostgreSQL para seus servidores. É por isso que nossos bancos de dados estão localizados em algum lugar da nuvem.

Mas surge um problema: precisamos conectar nosso serviço a um banco de dados, criar um tipo de banco de dados, transferir a credencial e gerenciá-la de alguma forma. Tudo isso geralmente é feito manualmente pelo administrador ou desenvolvedor do sistema. E não há problema quando há poucas aplicações. Quando há muitos deles, você precisa de uma colheitadeira. Existe tal colheitadeira - é o Service Broker. Ele permite usar um plugin especial para um cluster de nuvem pública e solicitar recursos do provedor por meio do Broker, como se fosse uma API. Você pode usar ferramentas nativas do Kubernetes para isso.

É muito simples. Você pode consultar, por exemplo, MySQL gerenciado no Azure com uma camada base (isso pode ser configurado). Utilizando a API do Azure, o banco de dados será criado e preparado para uso. Você não precisa interferir nisso, o plugin é responsável por isso. Por exemplo, OSBA (plugin do Azure) retornará a credencial ao serviço e a transmitirá ao Helm. Você poderá usar WordPress com MySQL em nuvem, não lidar com bancos de dados gerenciados e não se preocupar com serviços stateful internos.

Podemos dizer que o Helm atua como uma cola que, por um lado, permite implantar serviços e, por outro, consumir recursos dos provedores de nuvem.

Você pode escrever seu próprio plugin e usar toda essa história localmente. Então você simplesmente terá seu próprio plugin para o provedor de nuvem corporativo. Recomendo tentar essa abordagem, especialmente se você tiver uma escala grande e quiser implantar rapidamente o desenvolvimento, a preparação ou toda a infraestrutura de um recurso. Isso facilitará a vida de suas operações ou DevOps.

Outra descoberta que já mencionei é plugin helm-gcs, que permite usar Google-buckets (armazenamento de objetos) para armazenar gráficos do Helm.

Você só precisa de quatro comandos para começar a usá-lo:

1. instale o plugin;
2. iniciá-lo;
3. defina o caminho para o bucket, localizado no gcp;
4. publicar gráficos da maneira padrão.

A beleza é que o método gcp nativo será usado para autorização. Você pode usar uma conta de serviço, uma conta de desenvolvedor, o que quiser. É muito conveniente e não custa nada para operar. Se você, como eu, promove a filosofia opsless, isso será muito conveniente, especialmente para equipes pequenas.

Alternativas

Helm não é a única solução de gerenciamento de serviços. Há muitas dúvidas sobre isso, provavelmente por isso a terceira versão apareceu tão rapidamente. Claro que existem alternativas.

Podem ser soluções especializadas, por exemplo, Ksonnet ou Metaparticle. Você pode usar suas ferramentas clássicas de gerenciamento de infraestrutura (Ansible, Terraform, Chef, etc.) para os mesmos fins que falei.

Finalmente há uma solução Estrutura do Operador, cuja popularidade está crescendo.

Operator Framework é a principal alternativa do Helm a ser considerada.

É mais nativo para CNCF e Kubernetes, mas a barreira à entrada é muito maior, você precisa programar mais e descrever menos os manifestos.

Existem vários complementos, como Draft, Scaffold. Eles facilitam muito a vida, por exemplo, simplificam o ciclo de envio e lançamento do Helm para desenvolvedores implantarem um ambiente de teste. Eu os chamaria de capacitadores.

Aqui está um gráfico visual de onde tudo está.

No eixo x está o nível de seu controle pessoal sobre o que está acontecendo, na ordenada está o nível de natividade do Kubernetes. A versão 2 do Helm fica em algum lugar no meio. Na versão 3 não é enorme, mas tanto o controle quanto o nível de natividade foram melhorados. As soluções no nível Ksonnet ainda são inferiores até mesmo ao Helm 2. No entanto, vale a pena dar uma olhada para saber o que mais existe neste mundo. É claro que seu gerenciador de configuração estará sob seu controle, mas não é nativo do Kubernetes.

O Operator Framework é absolutamente nativo do Kubernetes e permite gerenciá-lo de maneira muito mais elegante e escrupulosa (mas lembre-se do nível de entrada). Em vez disso, isso é adequado para uma aplicação especializada e para a criação de gerenciamento para ela, em vez de uma colheitadeira em massa para empacotar um grande número de aplicações usando o Helm.

Os extensores simplesmente melhoram um pouco o controle, complementam o fluxo de trabalho ou economizam em pipelines de CI/CD.

O futuro de Helm

A boa notícia é que está chegando o Helm 3. A versão alfa do Helm 3.0.0-alpha.2 já foi lançada, você pode experimentá-la. É bastante estável, mas a funcionalidade ainda é limitada.

Por que você precisa do Helm 3? Em primeiro lugar, esta é uma história sobre desaparecimento de Tiller, como um componente. Isso, como você já entendeu, é um grande avanço, porque do ponto de vista da segurança da arquitetura tudo fica simplificado.

Quando o Helm 2 foi criado, na época do Kubernetes 1.8 ou até antes, muitos dos conceitos eram imaturos. Por exemplo, o conceito CRD está agora a ser implementado activamente e Helm irá usar CRDpara armazenar estruturas. Será possível utilizar apenas a parte cliente e não manter a parte servidor. Da mesma forma, use comandos nativos do Kubernetes para trabalhar com estruturas e recursos. Este é um enorme passo em frente.

Aparecerá suporte para repositórios nativos do OCI (Iniciativa Open Container). Esta é uma grande iniciativa, e Helm está interessado principalmente em publicar seus gráficos. Chega ao ponto que, por exemplo, o Docker Hub oferece suporte a muitos padrões OCI. Não estou supondo, mas talvez os provedores de repositórios Docker clássicos comecem a lhe dar a oportunidade de hospedar seus gráficos Helm.

A história controversa para mim é Suporte Lua, como um mecanismo de modelo para escrever scripts. Não sou um grande fã de Lua, mas esse seria um recurso totalmente opcional. Verifiquei isso 3 vezes - não será necessário usar Lua. Portanto, quem quiser poder usar Lua, quem gosta de Go, junte-se ao nosso enorme acampamento e use go-tmpl para isso.

Finalmente, o que eu definitivamente estava sentindo falta era emergência de esquema e validação de tipo de dados. Não haverá mais problemas com int ou string, não há necessidade de colocar zero entre aspas duplas. Um esquema JSONS aparecerá que permitirá descrever explicitamente isso para valores.

Será fortemente reformulado modelo orientado a eventos. Já foi descrito conceitualmente. Observe o branch do Helm 3 e você verá quantos eventos e ganchos e outras coisas foram adicionados, o que simplificará bastante e, por outro lado, adicionará controle sobre os processos de implantação e reações a eles.

O Helm 3 será mais simples, seguro e divertido, não porque não gostemos do Helm 2, mas porque o Kubernetes está se tornando mais avançado. Conseqüentemente, Helm pode usar os desenvolvimentos do Kubernetes e criar excelentes gerenciadores para o Kubernetes nele.

Outra boa notícia é que DevOpsConf Alexander Khayorov lhe dirá, os contêineres podem ser seguros? Lembramos que a conferência sobre integração de processos de desenvolvimento, teste e operação será realizada em Moscou 30 de setembro e 1º de outubro. Você ainda pode fazer isso até 20 de agosto enviar um relatório e conte-nos sobre sua experiência com a solução um de muitos tarefas da abordagem DevOps.

Acompanhe os pontos de verificação e as notícias da conferência em Boletim de Notícias и canal de telegrama.

Fonte: habr.com