Por que a conteinerização da infraestrutura de identidade legada é importante

Nos últimos anos, as organizações de médio a grande porte tiveram que passar por uma transformação significativa para se tornarem mais competitivas. Uma das linhas de ação mais ambiciosas tem sido melhorar a eficiência operacional “adotando a nuvem”, aproveitando aplicativos, plataformas e infraestrutura como serviço.

A infraestrutura de identidade antiga me lembra o “elefante na sala”. Você sabe que está lá, está ocupando muito espaço e exige muito esforço para lidar com isso. No dia a dia, você gostaria de evitá-lo, mas andar na ponta dos pés e constantemente fazer acomodações apenas para mantê-lo funcional está se tornando cada vez menos viável. A maior parte da infraestrutura de identidade legada é hospedada no local ou em nuvens privadas, sendo executada em servidores bare metal ou plataformas de virtualização de hardware, como o vSphere da VMware e outras. Combine esse código de software pesado (mas necessário) apenas com as bibliotecas do sistema operacional (OS) e as dependências necessárias em um executável leve que será executado consistentemente em qualquer infraestrutura, e você terá um “contêiner”. Mais portáteis do que uma máquina virtual (VM), os contêineres com eficiência de recursos são uma tecnologia comprovada e onipresente, além de uma ótima maneira de lidar com esse elefante de infraestrutura e facilitar o caminho para a modernização do IAM.

Mas vamos começar do começo. Neste post, explorarei algumas abordagens típicas de migração incremental para a nuvem e como elas são insuficientes no contexto da migração de serviços de identidade e autenticação.

Aplicativos de negócios “lift-and-shift”

Os aplicativos de negócios são combinados com uma infraestrutura de identidade legada, como o Active Directory, e produtos que estão chegando ao fim da vida útil (EOL). Embora seja possível resolver o primeiro usando as ferramentas de migração oferecidas pelo fornecedor da nuvem (Azure para Active Directory), isso não funciona para os produtos EOL. Adotar uma abordagem “lift-and-shift” para aplicativos de negócios, com a expectativa de que eles funcionem bem com uma infraestrutura de identidade mais moderna, é uma receita para o fracasso. Os ecossistemas de TI dos quais eles dependem não existem mais ou, se existirem, não estão em conformidade com esses aplicativos de negócios em termos de integração. Então, como podemos efetivamente mover nossos aplicativos de negócios para um ambiente de nuvem moderno de forma bem-sucedida?

Infraestrutura de identidade legada “lift-and-shift”

Como não podemos simplesmente esperar que nossos aplicativos de negócios funcionem no novo ambiente, uma ideia é “migrar e transferir” nossa infraestrutura de identidade legada para a nuvem como está, para que tudo corresponda às nossas configurações anteriores e, ao mesmo tempo, operar além do perímetro. Na prática, isso se traduzirá na configuração de várias máquinas virtuais na infraestrutura como serviço (IaaS) escolhida, como AWS ou Azure, para hospedar um espelho de nossa infraestrutura de identidade legada. Isso não é tão fácil quanto parece, pois teremos que criar uma imagem instantânea das VMs existentes (se estivermos virtualizando) e portá-las para qualquer hipervisor que o provedor de serviços de nuvem esteja usando. Quando conseguirmos executar a infraestrutura de identidade na nuvem, a configuração será afetada, pois as mudanças no ambiente não podem ser totalmente isoladas. Normalmente, isso acontece por meio de algum tipo de interface de usuário de administração e/ou por meio de descritores de configuração, desalinhados com as oportunidades de automação.
‍
Depois que tudo estiver funcionando com sucesso, como podemos tornar o trabalho de provisionamento de uma infraestrutura de identidade funcional reproduzível e reproduzível, para aproveitar as vantagens da automação?

Adotando a infraestrutura como código

Vamos dar uma olhada na definição da Wikipedia para infraestrutura como código:

Infraestrutura como código (IaC) é o processo de gerenciar e provisionar centros de dados de computadores por meio de arquivos de definição legíveis por máquina, em vez de configuração física de hardware ou ferramentas de configuração interativas. [1] A infraestrutura de TI gerenciada por esse processo compreende tanto equipamentos físicos, como servidores bare-metal, quanto máquinas virtuais e recursos de configuração associados.

Isso geralmente é implementado por meio da codificação de scripts de ações de provisionamento de infraestrutura, arquivos de configuração ou ambos. Há muitas pilhas de código aberto de boa qualidade para usar para isso, como Packer, Terraform e Ansible, para citar algumas. Ao adotar essa abordagem, você poderá implementar gradualmente as configurações de infraestrutura de identidade de forma rápida e consistente.

Embora a maioria das organizações já aproveite esse método para a TI de sua linha de negócios, aplicá-lo à infraestrutura de identidade legada apresenta alguns desafios:

• A infraestrutura de identidade foi implantada manualmente, provavelmente usando uma GUI, há pelo menos 10 a 15 anos, antes que a infraestrutura como código (IaC) existisse. Portanto, os tipos de configurações detalhadas originalmente aplicadas não estão disponíveis, o que, por sua vez, exige que sejam submetidas a engenharia reversa.
• Há muitas peças móveis: middleware, serviços de autenticação e autorização e diretórios, para citar alguns; cada um com uma área de cobertura significativa e um acoplamento estreito.
• Embora a maioria das ações de configuração possa ser executada a partir da interface de linha de comando (CLI), outras não podem, forçando-nos a lidar com APIs de produtos de baixo nível, o que aumenta a complexidade.

Usar somente máquinas virtuais remotas (VM) pode não ser suficiente

A maioria das organizações com um ecossistema de TI relativamente complexo provavelmente migrará suas VMs locais para as baseadas na nuvem, já que a combinação é individual. No entanto, com produtos de identidade legados, normalmente será necessário mais do que uma VM. Por exemplo, com uma implementação típica do CA Siteminder, haverá uma VM para o Secure Proxy Server (SPS), uma para o Policy Server, uma para o Policy Store e outra para a interface do administrador. Supondo que se espere que os serviços de identidade sejam altamente disponíveis e escaláveis, pelo menos mais uma VM por cada componente precisará ser alocada.

Mesmo com uma abordagem de IaC, criar imagens de VM, depois girá-las e mantê-las se traduzirá em um impacto negativo em sua conta de infraestrutura de nuvem, sem falar em dificultar o consumo da infraestrutura IAM por desenvolvedores de software e pessoal de DevOps. Operar ambientes separados de preparação e desenvolvimento aumentará sua carga de manutenção e seus custos em uma ordem de magnitude. Além da produção, os ambientes restantes serão consumidos apenas ocasionalmente e, eventualmente, ficarão inativos; no entanto, como a infraestrutura ainda está alocada, o preço total terá que ser pago.

Então, como podemos reduzir nossa área de cobertura de infraestrutura em nuvem e reduzir os custos associados? Como podemos aumentar a agilidade para tornar nossos serviços de identidade legados mais facilmente disponíveis para consumidores, como desenvolvedores e equipes de DevOps?

Encolhendo o elefante: contêineres para resgatar

A tecnologia de contêineres é considerada um avanço significativo. Ele melhora a eficiência e a portabilidade, ao mesmo tempo em que reduz a sobrecarga com a virtualização tradicional. Os contêineres Docker, especificamente, são onipresentes. Como todos os principais provedores de IaaS de nuvem pública oferecem suporte ao Docker, as organizações podem reduzir os custos e a complexidade enquanto permitem que o provedor de nuvem cuide da infraestrutura. Em vez de contornar com leveza os obstáculos desajeitados dos aplicativos legados elefantinos, podemos usar o Docker para colocá-los em contêineres para que sejam facilmente transportados para um ambiente em que possam ser úteis.

O que isso nos compra em termos de nossa migração do IAM para a nuvem?

Primeiramente, uma única máquina virtual pode executar qualquer número de contêineres. Assim, poderíamos alocar uma VM para executar todos os nossos ambientes de preparação, teste e desenvolvimento e uma segunda para produção. Em vez de ter uma VM dedicada para cada serviço do IAM, agora simplesmente usamos contêineres, promovendo a otimização de recursos e melhorias de custos à medida que os contêineres compartilham recursos (por exemplo, um sistema operacional) com o host.

Em segundo lugar, as equipes de desenvolvimento e DevOps agora podem executar uma réplica de uma infraestrutura de identidade legada completa na nuvem de sua preferência ou até mesmo em sua própria estação de trabalho.

Em terceiro lugar, já que a rotação de uma imagem do docker é extremamente rápida (pode levar menos de um segundo!) quando terminarmos, por exemplo, de testar a integração de um login único (SSO) com os serviços de autenticação legados em execução na nuvem, podemos simplesmente destruir o ambiente. Isso significa que não há faturas por capacidade não utilizada, além de mais recursos disponíveis para outros serviços IAM em contêineres.

Finalmente, sua infraestrutura de identidade legada pode se alinhar desde o primeiro dia com seus esforços de DevOps e o ciclo de vida de desenvolvimento de software (SDLC). Não é necessário concluir a modernização do IAM para começar a ver os benefícios. O quarto parece muito mais espaçoso sem aquele elefante no meio, não é?

‍

Como você pode começar?

Nossa próxima postagem no blog guiará você pelo processo de habilitação da infraestrutura como código e da conteinerização com o CA Siteminder.