

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Use AWS Secrets Manager em GitLab
<a name="integrating_gitlab"></a>

AWS Secrets Manager se integra com GitLab. Você pode aproveitar os segredos do Secrets Manager para proteger suas GitLab credenciais para que elas não sejam mais codificadas. GitLab Em vez disso, o [GitLab Runner](https://docs.gitlab.com/runner/) recupera esses segredos do Secrets Manager quando seu aplicativo executa um trabalho nos pipelines de GitLab CI/CD.

Para usar essa integração, você criará um [provedor de identidade OpenID Connect (OIDC) no IAM AWS Identity and Access Management e uma função do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html). Isso permite que o GitLab Runner acesse seu segredo do Secrets Manager. [Para obter mais informações sobre GitLab CI/CD e OIDC, consulte a documentação. GitLab](https://docs.gitlab.com/ci/cloud_services/aws/)

## Considerações
<a name="gitlab-integration-considerations"></a>

Se você estiver usando uma GitLab instância não pública, não poderá usar essa integração com o Secrets Manager. Em vez disso, consulte a [GitLab documentação de instâncias não públicas](https://docs.gitlab.com/ci/cloud_services/aws/#configure-a-non-public-gitlab-instance).

## Pré-requisitos
<a name="gitlab-integration-prerequisites"></a>

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

1. 

**Crie um AWS Secrets Manager segredo**

   Você precisará de um segredo do Secrets Manager que será recuperado em seu GitLab trabalho e eliminará a necessidade de codificar essas credenciais. Você precisará do ID secreto do Secrets Manager ao [configurar seu GitLab pipeline](#configure-gitlab-pipeline). Consulte [Crie um AWS Secrets Manager segredo](create_secret.md) para obter mais informações.

1. 

**Crie GitLab seu provedor OIDC no console do IAM.**

   Nesta etapa, você criará GitLab seu provedor OIDC no console do IAM. [Para obter mais informações, consulte [Criar um provedor de identidade e documentação do OpenID Connect (OIDC)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_providers_create_oidc.html). GitLab](https://docs.gitlab.com/ci/cloud_services/aws/)

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

   1. <a name="step2-oidc-provider"></a>Defina o `provider URL` para sua GitLab instância. Por exemplo, .**gitlab.example.com**

   1. <a name="step2-oidc-audience"></a>Configure `audience` ou `aud` como **sts.amazonaws.com**.

1. 

**Criar uma política e um perfil do IAM**

   Será necessário criar uma política e um perfil do IAM. Essa função é assumida por GitLab with [AWS Security Token Service (STS)](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html). Para obter mais informações, consulte [Criação de um perfil usando políticas de confiança personalizadas](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-custom.html).

   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**.
      + `Identity provider`Defina com o mesmo URL do provedor (a [GitLab instância](#step2-oidc-provider)) que você usou na etapa 2.
      + Defina `Audience` como o mesmo [público](#step2-oidc-audience) que você usou na etapa 2.

   1. Veja a seguir um exemplo de uma política de confiança que GitLab permite assumir funções. Sua política de confiança deve listar seu Conta da AWS GitLab URL e o [caminho do projeto](https://docs.gitlab.com/user/project/).  
****  

      ```
      {
        "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*"
                ]
              }
            }
          }
        ]
      }
      ```

   1. Você também precisará criar uma política do IAM para permitir o GitLab acesso AWS Secrets Manager a. É 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html).  
****  

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

## Integrando com AWS Secrets Manager GitLab
<a name="integrating-aws-secrets-manager-gitlab"></a>

Depois de concluir os pré-requisitos, você pode configurar GitLab para usar o Secrets Manager para proteger suas credenciais.

### Configurar o GitLab pipeline para usar o Secrets Manager
<a name="configure-gitlab-pipeline"></a>

Você precisará atualizar seu [arquivo de configuração de GitLab CI/CD](https://docs.gitlab.com/ci/yaml/yaml_optimization/) com as seguintes informações:
+ O público do token definido como STS.
+ O ID do segredo do Secrets Manager.
+ A função do IAM que você deseja que o GitLab Runner assuma ao executar trabalhos no GitLab pipeline.
+ O Região da AWS local onde o segredo está armazenado.

GitLab busca o segredo do Secrets Manager e armazena o valor em um arquivo temporário. O caminho para esse arquivo é armazenado em uma CI/CD variável, semelhante às variáveis [CI/CD do tipo de arquivo](https://docs.gitlab.com/ci/variables/#use-file-type-cicd-variables).

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

```
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](https://docs.gitlab.com/ci/secrets/aws_secrets_manager/).

Opcionalmente, você pode testar sua configuração do OIDC em. GitLab Consulte a [GitLab documentação para testar a configuração do OIDC](https://docs.gitlab.com/ci/cloud_services/aws/#test-the-oidc-configuration) para obter mais informações.

## Solução de problemas
<a name="troubleshooting-integration"></a>

O seguinte pode ajudá-lo a solucionar problemas comuns que você pode encontrar ao integrar o Secrets Manager com o. GitLab

### GitLab Problemas de tubulação
<a name="gitlab-pipeline-issues"></a>

Se você tiver problemas no GitLab pipeline, verifique o seguinte:
+ Seu arquivo YAML está formatado corretamente. Para obter mais informações, consulte a [documentação da GitLab](https://docs.gitlab.com/ee/ci/yaml/).
+ Seu GitLab funil está assumindo a função correta, tem as permissões apropriadas e acesso ao AWS Secrets Manager segredo correto.

### Recursos adicionais do
<a name="additional-resources"></a>

Os recursos a seguir podem ajudá-lo a solucionar problemas com GitLab e AWS Secrets Manager:
+ [GitLab Solução de problemas do OIDC](https://docs.gitlab.com/ci/cloud_services/aws/#troubleshooting)
+ [ GitLab Depurando o pipeline de CI/CD](https://docs.gitlab.com/ee/ci/troubleshooting.html)
+ [Solução de problemas](ascp-eks-installation.md#troubleshooting)