Alternar as credenciais do banco de dados sem reiniciar os contêineres

Criado por Josh Joy (AWS)

Resumo

Na Nuvem da Amazon Web Services (AWS), você pode usar o AWS Secrets Manager para alternar, gerenciar e recuperar credenciais de banco de dados durante o ciclo de vida deles. Usuários e aplicativos recuperam segredos com uma chamada para a API do Secrets Manager, removendo a necessidade de codificar informações confidenciais.

Se você estiver usando contêineres para workload de microsserviços, poderá armazenar credenciais com segurança no AWS Secrets Manager. Para separar a configuração do código, essas credenciais geralmente são injetadas no contêiner. No entanto, é importante alternar suas credenciais periodicamente e automaticamente. Também é importante oferecer suporte à capacidade de atualizar as credenciais após a revogação. Ao mesmo tempo, os aplicativos exigem a capacidade de alternar as credenciais e, ao mesmo tempo, reduzir qualquer impacto potencial na disponibilidade posterior.

Esse padrão descreve como alternar seus segredos protegidos com o AWS Secrets Manager em seus contêineres sem exigir que eles reiniciem. Além disso, esse padrão reduz o número de pesquisas de credenciais no Secrets Manager usando o componente de cache do lado do cliente do Secrets Manager. Ao usar o componente de cache do lado do cliente para atualizar as credenciais no aplicativo, o contêiner não precisa ser reiniciado para obter uma credencial alternada.

Esta abordagem funciona para Amazon Elastic Kubernetes Service (Amazon EKS) e Amazon Elastic Container Service (Amazon ECS).

Dois cenários são abordados. No cenário de usuário único, a credencial do banco de dados é atualizada na rotação secreta, detectando a credencial expirada. O cache de credenciais é instruído a atualizar o segredo e, em seguida, o aplicativo restabelece a conexão com o banco de dados. O componente de cache do lado do cliente armazena em cache a credencial dentro do aplicativo e ajuda a evitar o contato com o Secrets Manager para cada consulta de credencial. A credencial é alternada dentro do aplicativo sem a necessidade de forçar a atualização da credencial ao reiniciar o contêiner.

O segundo cenário alterna o segredo ao alternar entre dois usuários. Ter dois usuários ativos reduz a possibilidade de tempo de inatividade, pois as credenciais de um usuário estão sempre ativas. A rotação de credenciais de dois usuários é útil quando você tem uma grande implantação com clusters nos quais pode haver um pequeno atraso na propagação das atualizações de credenciais.

Pré-requisitos e limitações

Pré-requisitos

Limitações

Arquitetura

Arquitetura de destino

Cenário 1: alternância de uma credencial para um único usuário

No primeiro cenário, uma única credencial de banco de dados é alternada periodicamente pelo Secrets Manager. O contêiner do aplicativo é executado no Fargate. Quando a primeira conexão com o banco de dados é estabelecida, o contêiner do aplicativo busca a credencial do banco de dados para o Aurora. O componente de cache do Secrets Manager então armazena em cache a credencial para o estabelecimento futuro da conexão. Quando o período de rotação termina, a credencial expira e o banco de dados retorna um erro de autenticação. O aplicativo então busca a credencial alternada, invalida o cache e atualiza o cache de credenciais por meio do componente de cache do lado do cliente do Secrets Manager.

Nesse cenário, pode haver uma interrupção mínima enquanto a credencial está sendo alternada e as conexões obsoletas estão usando a credencial desatualizada. Essa preocupação pode ser resolvida usando o cenário de dois usuários.

Cenário 2: alternância de credenciais para dois usuários

No segundo cenário, duas credenciais de usuário do banco de dados (Alice e Bob) são alternadas periodicamente pelo Secrets Manager. O contêiner do aplicativo é executado em um cluster Fargate. Quando a primeira conexão com o banco de dados é estabelecida, o contêiner do aplicativo busca a credencial do banco de dados Aurora para o primeiro usuário (Alice). O componente de cache do Secrets Manager então armazena em cache a credencial para o estabelecimento futuro da conexão.

Embora existam dois usuários e credenciais, uma única credencial ativa é gerenciada pelo Secrets Manager. Nesse caso, o componente de cache expira periodicamente e busca a credencial mais recente. Se o período de alternância do Secrets Manager for maior que o tempo limite do cache, o componente de cache pega a credencial alternada para o segundo usuário (Bob). Por exemplo, se a expiração do cache for medida em minutos e o período de alternância for medido em dias, o componente de cache buscará a nova credencial como parte da atualização periódica do cache. Dessa forma, o tempo de inatividade é minimizado porque a credencial de cada usuário está ativa para uma alternância do Secrets Manager.

Automação e escala

Você pode usar CloudFormation a AWS para implantar esse padrão usando a infraestrutura como código. Isso compila e cria o contêiner do aplicativo, cria a tarefa do Fargate, implanta o contêiner no Fargate e configura o Secrets Manager com o Aurora. Para obter instruções de step-by-step implantação, consulte o arquivo readme.

Ferramentas

Ferramentas

Código

Código em Python de exemplo

Esse padrão usa o componente de cache do lado do cliente Python para o Secrets Manager para recuperar as credenciais de autenticação ao estabelecer a conexão com o banco de dados. O componente de cache do lado do cliente ajuda a evitar o contato com o Secrets Manager todas as vezes.

Agora, quando o período de rotação terminar, a credencial em cache expirará e a conexão com o banco de dados resultará em um erro de autenticação. Para o MySQL, o código de erro de autenticação é 1045. Este exemplo usa o Amazon Aurora para MySQL, embora você possa usar outro mecanismo, como o PostgreSQL. Após o erro de autenticação, o código de tratamento da exceção de conexão do banco de dados detecta o erro. Em seguida, informa-se o componente de cache do lado do cliente do Secrets Manager para atualizar o segredo e, em seguida, reautenticar e restabelecer a conexão com o banco de dados. Se você estiver usando o PostgreSQL ou outro mecanismo, deverá procurar o código de erro de autenticação correspondente.

O aplicativo de contêiner agora pode atualizar a senha do banco de dados com a senha alternada sem reiniciar o contêiner.

Coloque o código a seguir no código do seu aplicativo que manipula as conexões do banco de dados. Este exemplo usa o Django e subclassifica o backend do banco de dados com um invólucro de banco de dados para conexões. Se você estiver usando uma linguagem de programação ou biblioteca de conexão de banco de dados diferente, consulte sua biblioteca de conexão de banco de dados para analisar como subclassificar a recuperação de conexão de banco de dados.

    def get_new_connection(self, conn_params):
        try:
            logger.info("get connection")
            databasecredentials.get_conn_params_from_secrets_manager(conn_params)
            conn =super(DatabaseWrapper,self).get_new_connection(conn_params)
            return conn
        except MySQLdb.OperationalError as e:
            error_code=e.args[0]
            if error_code!=1045:
                raise e
 
            logger.info("Authentication error. Going to refresh secret and try again.")
            databasecredentials.refresh_now()
            databasecredentials.get_conn_params_from_secrets_manager(conn_params)
            conn=super(DatabaseWrapper,self).get_new_connection(conn_params)
            logger.info("Successfully refreshed secret and established new database connection.")
            return conn

Código AWS CloudFormation e Python

Épicos

Recursos relacionados

Crie um segredo do Secrets Manager

Crie um cluster do Amazon Aurora

Criar os componentes do Amazon ECS

Baixe e instale o componente de cache do lado do cliente do Secrets Manager

Anexos

Para acessar o conteúdo adicional associado a este documento, descompacte o seguinte arquivo: attachment.zip