Uso do AWS Secrets Manager no GitLab - AWS Secrets Manager

Uso do AWS Secrets Manager no GitLab

O AWS Secrets Manager integra-se ao GitLab. É possível aproveitar os segredos do Secrets Manager para proteger suas credenciais do GitLab de forma que elas não sejam mais codificadas no GitLab. Em vez disso, o GitLab Runner recupera esses segredos do Secrets Manager quando sua aplicação executa um trabalho nos pipelines de CI/CD do GitLab.

Para usar essa integração, você criará um provedor de identidade OpenID Connect (OIDC) no IAM AWS Identity and Access Management e um perfil do IAM. Isso permite que o GitLab Runner acesse seu segredo do Secrets Manager. Para obter mais informações sobre o GitLab CI/CD e o OIDC, consulte a documentação do GitLab.

Considerações

Se estiver usando uma instância do GitLab não pública, não poderá usar essa integração do Secrets Manager. Em vez disso, consulte a documentação do GitLab para instâncias não públicas.

Pré-requisitos

Para integrar o Secrets Manager com o GitLab, preencha os seguintes pré-requisitos:

  1. Criação de um segredo do AWS Secrets Manager

    Será necessário um segredo do Secrets Manager, que será recuperado em seu trabalho no GitLab e eliminará a necessidade de fazer a codificação rígida dessas credenciais. Você precisará do ID de segredo do Secrets Manager ao configurar seu pipeline do GitLab. Consulte Criação de um segredo do AWS Secrets Manager para obter mais informações.

  2. Faça do GitLab seu provedor de OIDC no console do IAM.

    Nesta etapa, você fará do GitLab seu provedor de OIDC no console do IAM. Para obter mais informações, consulte Criação de um provedor de identidade OpenID Connect (OIDC) e a documentação do GitLab.

    Ao criar o provedor OIDC no console do IAM, use as configurações a seguir:

    1. Defina o provider URL para sua instância do GitLab. Por exemplo, gitlab.example.com.

    2. Configure audience ou aud como sts.amazonaws.com.

  3. Criar uma política e um perfil do IAM

    Será necessário criar uma política e um perfil do IAM. Esse perfil é assumido pelo GitLab com o AWS Security Token Service (STS). Para obter mais informações, consulte Criação de um perfil usando políticas de confiança personalizadas.

    1. No console do IAM, use as configurações a seguir ao criar o perfil do IAM:

      • Defina Trusted entity type como Web identity.

      • Defina Group como your GitLab group.

      • Defina Identity provider com o mesmo URL do provedor (a instância do GitLab) que você usou na etapa 2.

      • Defina Audience como o mesmo público que você usou na etapa 2.

    2. O exemplo a seguir é de uma política de confiança que permite que o GitLab assuma perfis. Sua política de confiança deve listar sua Conta da AWS, o URL do GitLab e o caminho do projeto.

      { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRoleWithWebIdentity", "Principal": { "Federated": "arn:aws:iam::111122223333:oidc-provider/gitlab.example.com" }, "Condition": { "StringEquals": { "gitlab.example.com:aud": [ "sts.amazon.com" ] }, "StringLike": { "gitlab.example.com:sub": [ "project_path:mygroup/project-*:ref_type:branch-*:ref:main*" ] } } } ] }
    3. Você também precisará criar uma política do IAM para permitir acesso do GitLab ao AWS Secrets Manager. É possível adicionar essa política à sua política de confiança. Para obter mais informações, consulte Criação de políticas de IAM.

      { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:us-east-1:111122223333:secret:your-secret" } ] }

Integração do AWS Secrets Manager com o GitLab

Depois de concluir os pré-requisitos, será possível configurar o GitLab para usar o Secrets Manager para proteger suas credenciais.

Configuração do pipeline do GitLab para uso do Secrets Manager

Será necessário atualizar seu arquivo de configuração de CI/CD do GitLab com as informações a seguir:

  • O público do token definido como STS.

  • O ID do segredo do Secrets Manager.

  • O perfil do IAM que o GitLab Runner deve assumir ao executar trabalhos no pipeline do GitLab.

  • A Região da AWS onde o segredo está armazenado.

O GitLab busca o segredo do Secrets Manager e armazena o valor em um arquivo temporário. O caminho para esse arquivo é armazenado em uma variável de CI/CD, semelhante às variáveis de CI/CD de tipo de arquivo.

Veja a seguir um trecho do arquivo YAML para um arquivo de configuração de CI/CD do GitLab:

variables: AWS_REGION: us-east-1 AWS_ROLE_ARN: 'arn:aws:iam::111122223333:role/gitlab-role' job: id_tokens: AWS_ID_TOKEN: aud: 'sts.amazonaws.com' secrets: DATABASE_PASSWORD: aws_secrets_manager: secret_id: "arn:aws:secretsmanager:us-east-1:111122223333:secret:secret-name"

Para obter mais informações, consulte a documentação de integração do GitLab Secrets Manager.

Opcionalmente, é possível testar sua configuração de OIDC no GitLab. Consulte a documentação do GitLab para testes da configuração de OIDC para obter mais informações.

Solução de problemas

Os tópicos a seguir podem ajudá-lo a solucionar problemas comuns que podem ser encontrados ao integrar o Secrets Manager com o GitLab.

Problemas de pipeline do GitLab

Se você tiver problemas com o pipeline do GitLab, verifique o seguinte:

  • Seu arquivo YAML está formatado corretamente. Para obter mais informações, consulte a documentação do GitLab.

  • Seu pipeline do GitLab está assumindo o perfil correto, tem as permissões apropriadas e acesso ao segredo correto do AWS Secrets Manager.

Recursos adicionais

Os recursos a seguir podem ajudar a solucionar problemas com o GitLab e o AWS Secrets Manager.