Hoje, os contêineres não surpreenderão ninguém. Você ficará surpreso com a pergunta sobre segurança de contêineres. É especialmente interessante perguntar aos colegas que usam contêineres e microsserviços na produção com toda a seriedade sobre isso: muitas vezes vejo rostos surpresos e uma pergunta perplexa, eles dizem: "O que, por que isso?" Acontece que nós já sabemos sobre tecnologia (e como não podemos saber: parece que até crianças em idade escolar poderão em breve criar um cluster Kubernetes como uma classe nas aulas de tecnologia), mas ainda não aprenderam como proteger seus componentes. Talvez simplesmente não houvesse ninguém para ensinar.
Neste artigo e no
DevOops , teremos palestrantes que comeram um cachorro no tópico de soluções de segurança compatíveis com contêineres. Nós procuramos respostas para as perguntas mais simples sobre segurança na nuvem. É necessário começar a auto-educação com alguma coisa?
Os participantes:
Seth Vargo dirige o advogado do desenvolvedor no Google. Ele trabalhou anteriormente na HashiCorp, Chef Software, CustomInk e em várias outras startups em Pittsburgh. Ele é o autor do Learning Chef e defende a redução das desigualdades tecnológicas.
Liz Rice é uma evangelista técnica da Aqua Security, uma solução corporativa de segurança para implantação de aplicativos e contêiner na nuvem. Liz é uma pessoa muito famosa na comunidade, o presidente da Kubeon-s .
Oleg Chirukhin, editores do Grupo JUG.ru
Vamos começar com uma pergunta que determinará nossa discussão adicional. O que o DevOps significa para você? Como ele difere do SRE menos conhecido?
Por exemplo, em um trabalho anterior, quando me pediram para "implementar o DevOps", apenas andei pelo índice do SRE Book , peguei idéias e as apliquei uma a uma. Bem, ou pelo menos tentei transmiti-los a outras pessoas. O que você diz - esta é a abordagem correta?
Se falamos de DevOps, estamos falando de evitar o abismo, a partir da lacuna que normalmente estava entre os processos de desenvolvimento de código (Dev) e sua manutenção subsequente (Ops). Imagine que temos um muro alto, de um lado do qual os desenvolvedores se sentam, ele cria um código, joga-o por cima do muro. Do outro lado do muro estão pessoas envolvidas em apoio. Eles capturam o aplicativo transferido e começam a iniciar e manter. E essas pessoas conhecem os detalhes necessários durante a operação. Por exemplo, quais portas e onde serão alocadas e abertas.
Em vez de ter dois grupos separados de pessoas com interesses diferentes, quero fazê-los se comunicar, decidir o que fazer em seguida, determinar juntos quais objetivos eles tentarão alcançar juntos durante o dia de trabalho. Portanto, o DevOps é uma mudança na cultura da comunicação que ajuda colegas de diferentes equipes técnicas a trabalhar para o bem comum: criar valor para os negócios, implantar software e mantê-lo funcionando. Eu acho que essas são mudanças muito importantes e trazem novas ferramentas relacionadas: se você não tem uma cultura de comunicação, não faz muito sentido introduzir os mesmos processos de CI / CD.
Muitas vezes há confusão com os conceitos de DevOps e SRE. Algumas pessoas pensam que o SRE concorre com o DevOps, outras o consideram completamente diferentes, sobrepondo conceitos. Na minha opinião, eles não são concorrentes, mas amigos íntimos. Pense nas abordagens subjacentes ao DevOps - reduzindo custos organizacionais, tratando falhas como parte normal do fluxo de trabalho, introduzindo mudanças gradualmente, automatizando e implementando as ferramentas necessárias para isso e usando métricas para avaliar processos. Como você pode ver, tudo isso é muito abstrato: o DevOps não nos diz como reduzir custos organizacionais ou introduzir mudanças graduais, apenas diz que seria bom se elas fossem implementadas.
Agora vamos olhar para o SRE. Embora a abordagem do SRE tenha evoluído independentemente da abordagem do DevOps, o SRE é, pode-se dizer, uma implementação dos princípios do DevOps: se você imaginar o DevOps como uma classe abstrata ou interface na programação, o SRE será uma classe concreta que implementa essa interface. O SRE definiu claramente abordagens para uma série de coisas e conceitos: propriedade conjunta, compartilhamento de riscos, post-mortem, coleta e acúmulo de valores métricos e muito mais. Portanto, é mais conveniente para as organizações falar sobre a adoção do SRE devido à presença de processos e entidades muito compreensíveis.
Você acha que o termo "engenheiro do DevOps" está correto? Pode ser substituído de alguma maneira?
Pessoalmente, não acredito que o conceito de "engenheiro de DevOps" exista. Você pode ler com mais detalhes no meu artigo “10 mitos do DevOps” que “o DevOps” é na verdade uma ideologia: mais comunicação e cooperação entre unidades organizacionais diferentes, mas essencialmente conectadas. Embora hoje pareça bastante sensato e familiar, a princípio tal abordagem despertou elogios e críticas duras. Desde então, muitas organizações, incluindo Etsy, Facebook e Flick, implementaram surpreendentemente com sucesso os princípios de DevOps.
Portanto, nenhuma dessas organizações contratou "engenheiros de DevOps". O sucesso da implementação pode ser atribuído à cooperação interna emergente das equipes e à disposição de mudar seus processos e procedimentos existentes para alcançar um objetivo comum. O papel do chamado "engenheiro de DevOps" era incentivar a colaboração entre grupos e garantir que as unidades organizacionais trocassem regularmente idéias e objetivos. Na verdade, já temos essas pessoas hoje e as chamamos de "gerentes".
Vou acrescentar mais um momento. Quando nomeamos alguém para uma posição ou função específica, começamos a esperar coisas e ações bastante específicas dele, por isso é importante escolher um cargo. Mas os nomes exatos das postagens podem diferir devido às realidades e tradições locais adotadas pela organização, por isso é importante não o nome em si, mas o equilíbrio entre as postagens de todas as pessoas que trabalham na empresa.
Há pouco tempo, conversei com uma pessoa que trabalhava em uma organização bastante grande e, por isso, eles criaram uma equipe de vários funcionários e a chamaram de equipe de infraestrutura. Depois, essa equipe foi renomeada para outra coisa e, depois de um tempo, outra equipe foi criada, e agora foi chamada de equipe de infraestrutura - como resultado, todos ficaram confusos: quem são os "especialistas em infraestrutura" e qual é o seu papel.
Na minha opinião, o mais importante não é a existência de uma equipe ou posição com um nome específico, mas a presença na organização de um entendimento claro de quem é responsável por quê. Não importa se eles os chamam de SRE ou DevOps: o principal é entender o que um nome específico significa para essa organização em particular.
Liz, você está consultando, como explica os princípios do DevOps para as empresas clientes? Eles parecem bastante abstratos e um pouco difíceis de explicar. Ou talvez você tenha desenvolvido algum tipo de abordagem que permita transmitir essas idéias aos clientes?
Depende do objetivo. Muitas pessoas e empresas com quem eu me comunico como parte das consultas nos procuram e dizem que desejam implantar Kubernetes e contêineres. Mas antes de falar sobre tecnologia, você precisa entender por que eles estão tentando tomar essas medidas. E acontece que os benefícios esperados da mudança geralmente se resumem ao desejo de ser mais flexível. Daí o movimento na direção em que as equipes técnicas poderiam divulgar os resultados de seu trabalho mais rapidamente, algo assim, explicado “nos dedos”. Nesse ponto, é útil mudar a conversa para o lado de que o problema da falta de cultura (hábitos, se você preferir) de comunicação entre os membros da equipe não será ajudado por qualquer "lançamento" de novas tecnologias, de que a comunicação é um recurso importante.
Além disso, como muitas vezes me envolvo na melhoria da segurança das soluções, nossa conversa muda para “Dev - ** Sec ** - Ops”, e acontece que o sistema deve ser construído para que a segurança seja resolvida da melhor maneira possível. nos estágios iniciais dos processos, e não apenas abordamos a questão da maneira antiquada: primeiro escrevemos o código do aplicativo, depois o implantamos, depois o passamos para o serviço de manutenção, e somente no final alguém começa a pensar na segurança do que está sendo executado.
De fato, muitos problemas de segurança são mais baratos e fáceis de resolver no início do processo, mas você precisa colocar muitos pontos no projeto desde o início. Por exemplo, se você pretende trabalhar com contêineres, precisa se preocupar que as imagens sejam coletadas de uma maneira bastante segura. Pode ser útil examiná-los em busca de vulnerabilidades, a fim de pelo menos evitar a implantação de software com problemas de segurança já conhecidos. Talvez você tente configurar os contêineres para que o software neles não inicie por padrão pela raiz (com o objetivo de simplificar, sem necessidade especial, eles são feitos na montagem dos contêineres). Se você seguir estas etapas, no final, receberá um aumento na segurança do seu aplicativo e poderá, no contexto de todo esse DevOps, falar sobre a cultura do SecOps.
No entanto, isso significa que os desenvolvedores, na verdade não sendo especialistas em segurança de aplicativos, são forçados a pensar não apenas no código do aplicativo, mas também a criar seus próprios sistemas de segurança. Na sua opinião, qual deveria ser o conjunto mínimo de habilidades para um desenvolvedor de software ou engenheiro operacional moderno?
Você e eu, gostemos ou não, constantemente vemos o surgimento de novas regras e requisitos que, em algum momento, são necessários para cumprir e cumprir: tomemos, por exemplo, o mesmo RGPD. O surgimento e a existência desses regulamentos significa que um número crescente de pessoas deve ter uma sensação de segurança. Por exemplo, hoje você não pode mais armazenar nomes de usuário e senhas na forma de texto sem formatação nos campos do banco de dados - isso não é mais considerado pelo menos tolerável. Eu diria que no setor já existem requisitos claros para todos de "higiene".
Os próprios fabricantes de ferramentas e infra-estruturas têm um impacto significativo nesse processo, tentando projetar e alterar sistemas para que os usuários possam criar aplicativos e sistemas mais seguros desde o início. Por exemplo, no Kubernetes no ano passado, muitas das configurações padrão e os valores dos parâmetros foram alterados para maior segurança, e isso é realmente muito legal. Anteriormente, por padrão, o servidor da API estava aberto para acesso anônimo - isso não é exatamente o que você espera ver "pronto para uso". Agora, coisas como controle de acesso baseado em funções apareceram, então agora temos permissões (sim, "prontas para uso") e, quando você inicia o Kubernetes pela primeira vez, não está aberto ao mundo inteiro, está protegido por padrão. Eu acho que essa é uma boa maneira de tornar a segurança disponível para todos no decorrer de processos familiares, porque não precisamos alterar constantemente os valores padrão para valores seguros (que, além disso, precisavam ser lembrados).
Pessoalmente, acredito que todo engenheiro de software deve ter pelo menos um entendimento básico de segurança. Coisas como as abordagens do OWASP (Projeto de segurança de aplicativos da Web abertos) são úteis, mas, em última análise, os engenheiros precisam ser autodidatas. É improvável que todo engenheiro possua um Ph.D. em criptografia, mas se queremos que nossos colegas levem a segurança a sério, devemos facilitar a tomada de decisões corretas. É aqui que ferramentas como o Vault podem ajudar - e equipes e profissionais de segurança podem tomar decisões e fornecer "segurança como uma API".
Se bem entendi, há uma tendência de transformar tudo em código. Tudo como código. Infraestrutura como código, processos como código, código como código. Quais são as implicações?
Antes de falarmos sobre as consequências, precisamos falar sobre os benefícios. O código existe há muito tempo. Os aplicativos sempre foram "códigos" e, durante esse período, um extenso ecossistema de ferramentas e processos foi criado para apoiar e melhorar o processo de desenvolvimento de aplicativos (CI / CD, fiapos, ferramentas para o desenvolvimento conjunto, etc.). Tendo descrito a infraestrutura como código, processos como código, segurança como código, podemos usar o mesmo ecossistema, sem pagar nada a mais por isso. Você pode desenvolver conjuntamente alterações de infraestrutura, fazer revisões de políticas etc. Você pode testar as alterações na infraestrutura antes de implantá-las. Esses são apenas alguns dos benefícios que acompanham a tradução de algo em código.
Eu acho que as maiores consequências são tempo e complexidade. Quando você trabalha com algo "semelhante ao código" (por exemplo, através do Terraform, Vault, CloudFormation, Deployment Manager, etc.), às vezes você precisa encontrar discrepâncias entre o que está escrito no código e o que realmente acontece na nuvem A modelagem de relacionamentos complexos às vezes é difícil de ser feita visualmente, principalmente considerando a escala. Além disso, podemos encontrar imprecisões de abstrações - por exemplo, um script que trabalha com a API pode não perceber o estado atual das coisas, conforme é exibido aos usuários por meio da interface da web. No entanto, com o tempo, a complexidade diminui e a flexibilidade retorna.
Código e outros modelos formais são um campo adequado para análise e aprendizado de máquina. Quando exatamente os robôs nos substituirão? Como devemos responder?
Os robôs podem configurar o Kubernetes sem humanos? Em particular, pode acontecer que algumas profissões (como um administrador de sistemas ou um testador de software com um alto nível de interatividade - uma palavra socialmente aceitável para um "testador manual") simplesmente desapareçam?
Não acho que as pessoas desapareçam, mas suspeito que alguns dos empregos que temos hoje não serão salvos no futuro. Eu moro em Pittsburgh, a capital mundial dos sistemas de controle de carros autônomos, e vejo carros autônomos literalmente todos os dias. No futuro, é claro, os taxistas serão substituídos por tecnologias de direção robótica. Talvez não imediatamente, mas depois de 10 anos ou mais, mas esse futuro inevitavelmente virá. No entanto, acho que os motoristas de táxi não desaparecerão. A humanidade está constantemente se reinventando.
Acredito que o mesmo possa ser dito sobre o aprendizado de máquina no campo da administração. Espero mais IA para tornar nossos sistemas mais estáveis e resilientes, e acho que podemos decidir combater essa abordagem - ou aceitá-la. O papel dos administradores de sistemas tradicionais pode ser substituído por alguém que controla o sistema de IA, mas isso não significa que as próprias pessoas desaparecerão. Tivemos as mesmas mudanças em vários setores em que a tecnologia e a inovação proporcionavam maior velocidade e precisão do que as pessoas, mas no final, alguém precisa seguir os robôs :).
Imagine que uma equipe de desenvolvimento regular crie um aplicativo da Web, coloque-o em um cluster Kubernetes. Como podemos garantir que o aplicativo seja seguro? Contrate um hacker ou especialista em blackhat que esteja tentando encontrar deficiências de segurança ou existem maneiras menos complicadas?
Nós da Aqua Security lançamos recentemente uma ferramenta de código aberto chamada kube-hunter . Ele é capaz de testar o Kubernetes quanto a invasão ou penetração - tornando-o um teste bastante simples. Você pode usar essa ferramenta e testar seu próprio cluster e certamente aprenderá algo interessante para si mesmo, especialmente se sua instalação foi baseada na versão antiga do Kubernetes, onde as configurações padrão eram menos seguras - você pode ter, por exemplo, portas abertas.
Todos ouvimos histórias sobre pessoas que "esqueceram" de fechar seu painel de controle de cluster do acesso gratuito a toda a Internet, de modo que o objetivo de criar o kube-hunter era verificar nosso próprio sistema e garantir que ele estivesse protegido. Em nossa opinião, há muito tempo os hackers examinam os hosts na Internet em busca de recursos e portas abertos e conhecidos, portanto, o painel de controle do Kubernetes, que por acaso não está protegido (e, portanto, aberto a todos), pode não ser tão difícil de encontrar, especialmente com ferramentas que eles estão acostumados a usar.
Queremos que o hunter ajude os administradores comuns do Kubernetes a entenderem melhor se houver problemas de configuração em sua implantação; portanto, ele foi projetado exclusivamente para o Kubernetes e relata que foi encontrado em um idioma que os usuários do Kubernetes entendem. Portanto, informaremos que você não abriu nenhuma porta 6443, mas, digamos, acesso a esse componente específico do Kubernetes. Portanto, é mais fácil para as pessoas determinar se o que encontraram é um problema com uma configuração que enfraquece a segurança e se vale a pena corrigi-la imediatamente - sem ser um especialista em segurança do Kubernetes. Queremos tentar disponibilizar essas verificações a qualquer momento, sem a necessidade de especialistas externos.
Há uma observação: muitos não estão mais interessados no que está dentro dos contêineres que lançam.
Sim, e eles não têm idéia de quais dependências foram construídas nesses contêineres. Embora, se você planeja usar a abordagem de contêiner para implantar o serviço, parece razoável descobrir que tipo de software está dentro dessa ou daquela imagem. Mas isso não é um problema da própria abordagem de contêiner, é apenas uma atitude de segurança por parte daqueles que usam a abordagem.
Não é tão difícil fazer tudo de maneira correta e confiável. Digamos, ao entrar no mundo da nuvem, você precisa começar a usar ferramentas adicionais - o que certamente adicionará níveis adicionais de segurança.
As nuvens têm suas próprias especificidades. Por exemplo, muitas vezes conheço o equívoco de que, no mundo das nuvens, uma ferramenta com a qual as pessoas estão acostumadas nos velhos tempos fará automaticamente tudo o que precisa. De certa forma, eles estão certos: digamos que você possa usar a lista usual (e sempre trabalhada) de configurações de firewall, e isso aumentará a segurança, mas algumas das ferramentas antigas não são mais adequadas hoje. Por exemplo, se você implantar uma imagem de contêiner e usar a antiga ferramenta familiar para verificar vulnerabilidades, se o scanner não souber procurar dentro da imagem, ele simplesmente não encontrará nada e você terá (possivelmente falsa) confiança de que tudo está em ordem.
Gosto muito que quando você passa para a arquitetura de microsserviços, obtém um número bastante grande de pequenas funções dispostas em contêineres (cujo conteúdo está na palma da sua mão) e pode ver o tráfego entre eles. Cada um dos contêineres pode ser percebido como uma espécie de caixa preta, da qual são esperadas ações estritamente definidas. E assim que este ou aquele recipiente começa a se comportar de maneira inesperada ou a produzir resultados estranhos, torna-se possível responder a isso. Quanto melhores as imagens específicas dos contêineres forem montadas e configuradas, mais compreensível será se elas funcionarão corretamente.
E como pegar anomalias? Usa algo como heurística de antivírus, redes neurais?
Durante o ciclo de vida do software, usamos várias ferramentas de segurança. runtime enforcer — , , . «», , , nginx, , nginx . , , «» , . , , . : , , .
. Serverless , , . . « »? , ?
, severless , , , . serverless — . severless-, «», . , «- ». severless. serverless- . «» , ( «» ) .
serverless – « ». serverless- pub/sub, , Redis . , , - () .
severless- , . , , , serverless- . - . , , , . serverless, - .
, serverless- . , , . ?
, , — , , , DevOps. , , , , .
, , : YAML. , Kubernetes Kubernetes, YAML. , 30 000 YAML. , , , 30 000 YAML, , , .
, Kubernetes . , , ?
Kubernetes , . , , , , - , . , , YAML- , , Kubernetes . , . , .
, Kubernetes — , . . , Kubernetes CNCF graduated, , , , , CNCF .
, : YAML, , . , YAML Kubernetes.
, YAML, , , , YAML. , , , - YAML .
, Kubernetes, , ?
Boa pergunta , , , , . – Istio ( service mesh), 1.0. , , , «».
, - , .
, ?
C . , , , , !
! , : — .
DevOops 2018 «Modern security with microservices and the cloud» , «Practical steps for securing your container deployment» . .