fbpx

DevSecOps – seja independente novamente

Compartilhar no facebook
Compartilhar no linkedin
Compartilhar no twitter
Compartilhar no whatsapp
Compartilhar no telegram

O que os efeitos das notícias dos últimos meses podem ter a ver com o gerenciamento de riscos e a presunção de armazenamento, e por que é um componente elementar do DevSecOps?

O que aconteceu até agora

Repetidamente, mudanças aconteceram que colocaram em movimento coisas que foram consideradas como tendo sido definidas.

Em alguns casos, os serviços ou produtos estão disponíveis gratuitamente há muitos anos ou o tipo de restrição não mudou. Aproveito uma das últimas mudanças como uma ocasião para mostrar o comportamento resultante e formular soluções que o ajudem a lidar com ele.

No desenvolvimento de software, os repositórios são um dos elementos centrais que permitem lidar com eficiência com a abundância de dependências em um ambiente de software.

Uma grande variedade de tipos e tecnologias associadas evoluíram ao longo das décadas. Mas há uma abordagem comum que resultou principalmente em uma autoridade central global que é vista como uma referência essencial.

Como exemplo, gostaria de mostrar brevemente como pode ser uma pilha mínima de tecnologia hoje.

Java é usado para o próprio aplicativo, cujas dependências são definidas usando o maven. Para isso, precisamos de acesso aos repositórios maven.

Repositórios Debian [Por que os repositórios Debian são de missão crítica ..] usados ​​para o sistema operacional no qual o aplicativo está sendo executado.

Os componentes que são empacotados em imagens Docker usam registros Docker e, finalmente, os aplicativos orquestrados em uma composição de imagens Docker usando Kubernetes.

Só aqui, estamos lidando com quatro tipos de repositório diferentes. Neste ponto, deixei de fora a necessidade de repositórios genéricos para fornecer as ferramentas necessárias usadas no pipeline DevSecOps.

DockerHub e seu domínio

O exemplo que me inspirou a escrever este artigo foram os anúncios do DockerHub.

O acesso a esse serviço era gratuito e não havia outras restrições quanto ao espaço e à duração do armazenamento para imagens do Docker disponíveis gratuitamente.

Este fato levou a um grande número de projetos de código aberto usando este repositório para seus propósitos. Com o passar dos anos, foi formada uma rede inteira de dependências entre essas imagens.

O Docker Hub foi notícia recentemente por dois motivos.

Restrições de armazenamento

Anteriormente, as imagens do Docker eram armazenadas indefinidamente no Dockerhub.

Por um lado, isso significava que ninguém se importava com o espaço de armazenamento das imagens do Docker. Por outro lado, quase todo mundo está contando com isso para não mudar novamente.

Infelizmente, isso agora mudou. O período de retenção para imagens inativas do Docker foi reduzido para seis meses.

O que não parece particularmente crítico no início acaba sendo bastante desconfortável em detalhes.

Baixar Throttling

O Docker limitou a taxa de download a 100 pulls por seis horas para usuários anônimos e 200 pulls por seis horas para contas gratuitas.

O número 200 parece bastante suportável.

No entanto, faz sentido dar uma olhada mais detalhada aqui. 200 consultas / 6h são 200 consultas / 360min. Estamos falando de 0,55 consultas / minuto a uma taxa de consulta constante.

Primeiro, muitos sistemas fazem mais de uma compilação e, portanto, solicitações a cada 2 minutos. Em segundo lugar, se o limite for atingido, pode levar mais de meio dia útil para recuperar o acesso.

Este último deve ser considerado muito crítico. Regra geral, valores-limite dados por hora, o que só conduz a um atraso de pouco menos de uma hora. Seis horas é uma ordem de magnitude diferente.

Maven e MavenCentral

Se você olhar para as diferentes tecnologias, uma monocultura semelhante surge na área de Maven.

Aqui está o maven-central, um ponto singular operado por uma empresa. Uma empresa maior comprou esta empresa. O que isso significa para o futuro deste repositório?

Eu não sei. No entanto, não é incomum que os custos sejam otimizados após uma aquisição por outra empresa. Uma questão legítima surge aqui; Qual é a vantagem econômica do operador de uma infraestrutura tão central e gratuita?

JDKs

Houve tantas mudanças estruturais aqui que nem tenho certeza de qual é o nome oficial.

Mas há uma coisa que observo com olhos de águia em projetos.

Diferentes versões, plataformas e provedores de JDKs resultam em uma fonte de alegria em projetos LTS que não deve ser subestimada.

Também aqui não é garantido por quanto tempo os provedores manterão os respectivos builds de um JDK para uma plataforma. O que está planejado hoje pode ser otimizado amanhã.

Aqui, também, você deve dar uma olhada nos JDKs que são usados ​​não apenas internamente, mas também pelos clientes.

Quem tem em estoque todos os instaladores para os JDKs em uso? Esses JDKs também são usados ​​em sua própria rota de CI ou você confia na disponibilidade de imagens específicas do Docker?

Independência moderada

Como isso pode ser combatido agora? A resposta é direta.

Você obtém tudo o que precisa apenas uma vez e depois salva em seus sistemas.

E, portanto, estamos lutando contra os esforços dos últimos anos. Como na maioria dos outros casos, o uso moderado dessa abordagem é recomendado.

Mais importante do que nunca é o uso sensato dos recursos disponíveis gratuitamente. Pode ajudar se uma tática de retenção rigorosa for usada.

Nem tudo deve ser guardado indefinidamente. Muitos elementos que são mantidos nos caches não são mais necessários depois de um tempo.

O manuseio sofisticado de repositórios e o aninhamento de recursos ajudam aqui. Infelizmente, não posso entrar em muitos detalhes aqui, mas isso pode ser observado de forma resumida.

A estrutura dos respectivos repositórios permite, por um lado, criar composições de betão e, por outro lado, efectuar uma manutenção muito eficiente.

As fontes devem ser mantidas em repositórios individuais e depois mescladas usando repositórios virtuais. Este processo pode ser desenvolvido de forma tão eficiente que pode até reduzir drasticamente o número de ciclos de construção.

DevSecOps – Minimização de Risco

Há outra vantagem em lidar com o assunto da “independência”.

Porque todos os arquivos que são mantidos em suas estruturas podem ser analisados ​​em relação a vulnerabilidades e conformidade, agora quando esses elementos estão em um lugar, em um gerenciador de repositório, tenho um local central onde posso digitalizá-los.

O resultado é um gráfico de dependência completo que inclui as dependências de um aplicativo, mas também o ambiente de trabalho associado.

Essa, por sua vez, é uma das declarações críticas quando você volta ao tópico de DevSecOps.

Segurança é como qualidade! Não é apenas uma ferramenta; não é apenas uma pessoa responsável por isso. É uma filosofia que deve percorrer toda a cadeia de valor.