# Uso de gMSA em contêineres do Linux no Fargate
O Amazon ECS oferece suporte à autenticação do Active Directory para contêineres do Linux no Fargate por meio de um tipo especial de conta de serviço denominada *Conta de serviço gerenciada por grupo* (gMSA).
Aplicações de rede baseadas no Linux, como as aplicações .NET Core, podem usar o Active Directory para facilitar o gerenciamento da autenticação e da autorização entre usuários e serviços. É possível usar esse recurso criando aplicações que se integram ao Active Directory e são executadas em servidores associados ao domínio. Mas, como os contêineres do Linux não podem ser associados a um domínio, você precisa configurar um contêiner do Linux para ser executado com o gMSA.
## Considerações
Considere o seguinte antes de usar o gMSA em contêineres do Linux no Fargate:
+ Você deve estar executando a versão da plataforma 1.4 ou posterior.
+ Talvez você precise de um computador Windows associado ao domínio para concluir os pré-requisitos. Por exemplo, é possível que seja preciso um computador Windows associado ao domínio para criar o gMSA no Active Directory com o PowerShell. As ferramentas PowerShell do Active Director RSAT estão disponíveis somente para Windows. Para obter mais informações, consulte [Instalação das ferramentas de administração do Active Directory](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_install_ad_tools.html).
+ Você deve usar o **gMSA sem domínio**.
O Amazon ECS usa um arquivo de especificação de credenciais do Active Directory (CredSpec). Esse arquivo contém os metadados de gMSA usados para propagar o contexto da conta de gMSA para o contêiner. Você gera o arquivo CredSpec e o armazena em um bucket do Amazon S3.
+ Uma tarefa só é compatível com um Active Directory.
## Pré-requisitos
Antes de usar o recurso gMSA para contêineres do Linux com o Amazon ECS, verifique se você concluiu o seguinte:
+ Você configurou um domínio do Active Directory com os recursos que deseja que seus contêineres acessem. O Amazon ECS oferece suporte às configurações a seguir:
+ Um Active Directory Directory Service. O Directory Service é um Active Directory gerenciado pela AWS e hospedado no Amazon EC2. Para obter mais informações, consulte [Conceitos básicos do Microsoft AD gerenciado pela AWS](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_getting_started.html) no *Guia de administração do AWS Directory Service*.
+ Um Active Directory on-premises. Você deve garantir que a instância de contêiner Linux do Amazon ECS possa se associar ao domínio. Para obter mais informações, consulte [AWS Direct Connect](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-direct-connect-network-to-amazon.html).
+ Você tem uma conta existente do gMSA no Active Directory e um usuário com permissão para acessar a conta de serviço do gMSA. Para obter mais informações, consulte [Crie um usuário do Active Directory para gMSA sem domínio](#fargate-linux-gmsa-initial-domainless).
+ Você tem um bucket do Amazon S3. Para obter mais informações, consulte [Como criar um bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) no *Guia do usuário do Amazon S3*.
## Configuração de contêineres do Linux compatíveis com o gMSA no Amazon ECS
**Preparar a infraestrutura**
As etapas a seguir são considerações e configurações que são executadas uma vez.
+
**Crie um usuário do Active Directory para gMSA sem domínio**
Ao usar gMSA sem domínio, o contêiner não é associado ao domínio. Outras aplicações executadas no contêiner não podem usar as credenciais para acessar o domínio. Tarefas que usam um domínio diferente podem ser executadas no mesmo contêiner. Forneça o nome de um segredo no AWS Secrets Manager no arquivo CredSpec. O segredo deve conter um nome de usuário, uma senha e o domínio no qual fazer login.
Esse recurso é semelhante ao recurso *gMSA support for non-domain-joined container hosts*. Para obter mais informações sobre o recurso do Windows, consulte [Arquitetura e melhorias do gMSA](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts#gmsa-architecture-and-improvements) no site do Microsoft Learn.
1. Configure um usuário em seu domínio do Active Directory. O usuário no Active Directory deve ter permissão para acessar a conta de serviço do gMSA que você usa nas tarefas.
1. Você tem uma VPC e sub-redes que podem resolver o nome de domínio do Active Directory. Configure a VPC com opções de DHCP com o nome de domínio que direciona ao nome de serviço do Active Directory. Para obter informações sobre como configurar opções de DHCP em uma VPC, consulte [Trabalhar com conjuntos de opções DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/DHCPOptionSet.html) no *Guia do usuário da Amazon Virtual Private Cloud*.
1. Criar um segredo no AWS Secrets Manager.
1. Crie o arquivo de especificação da credencial.
**Configuração de permissões e segredos**
Execute as etapas a seguir uma vez para cada aplicação e cada definição de tarefa. Use as práticas recomendadas de concessão de privilégio mínimo e restrinja as permissões usadas na política. Dessa forma, cada tarefa só pode ler os segredos de que precisa.
1. Crie um usuário no seu domínio do Active Directory. O usuário no Active Directory deve ter permissão para acessar as contas de serviço do gMSA que você usa nas tarefas.
1. Crie um segredo no , depois de criar o usuário no Active Directory AWS Secrets Manager. Para obter mais informações, consulte [Criar um segredo no AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create_secret.html).
1. Insira o nome de usuário, a senha e o domínio do usuário nos pares de valores-chave JSON denominados `username`, `password` e `domainName`, respectivamente.
```
{"username":"{{username}}","password":"{{passw0rd}}", "domainName":"example.com"}
```
1. É preciso adicionar as permissões a seguir como uma política em linha ao perfil do IAM de execução da tarefa. Isso dá ao daemon `credentials-fetcher` acesso ao segredo do Secrets Manager. Substitua o exemplo `MySecret` pelo nome do recurso da Amazon (ARN) do seu segredo na lista `Resource`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue"
],
"Resource": [
"{{arn:aws:secretsmanager:us-east-1:{{111122223333}}:secret:MySecret}}"
]
}
]
}
```
------
**nota**
Se você usar sua própria chave KMS para criptografar seu segredo, deverá adicionar as permissões necessárias a esse perfil e adicioná-lo à política de chaves AWS KMS.
1. Adicione a especificação da credencial a um bucket do Amazon S3. Em seguida, referencie o nome do recurso da Amazon (ARN) do bucket do Amazon S3 no campo `credentialSpecs` da definição de tarefa.
```
{
"family": "",
"executionRoleArn": "",
"containerDefinitions": [
{
"name": "",
...
"credentialSpecs": [
"credentialspecdomainless:arn:aws:s3:::{{${BucketName}/${ObjectName}}}"
],
...
}
],
...
}
```
Para fornecer às suas tarefas acesso ao bucket do S3, adicione as permissões a seguir como uma política em linha ao perfil do IAM de execução da tarefa do Amazon ECS.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor",
"Effect": "Allow",
"Action": [
"s3:GetObjectVersion",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::{{{bucket_name}}}",
"arn:aws:s3:::{{{bucket_name}/{object}}}"
]
}
]
}
```
------
## Arquivo de especificação de credenciais
O Amazon ECS usa um arquivo de especificação de credenciais do Active Directory (*CredSpec*). Esse arquivo contém os metadados do gMSA usados para propagar o contexto da conta gMSA para o contêiner de Linux. Você gera o CredSpec e o referencia no campo `credentialSpecs` em sua definição de tarefa. O arquivo CredSpec não contém nenhum segredo.
Veja a seguir um exemplo de arquivo CredSpec.
```
{
"CmsPlugins": [
"ActiveDirectory"
],
"DomainJoinConfig": {
"Sid": "S-1-5-21-2554468230-2647958158-2204241789",
"MachineAccountName": "WebApp01",
"Guid": "8665abd4-e947-4dd0-9a51-f8254943c90b",
"DnsTreeName": "example.com",
"DnsName": "example.com",
"NetBiosName": "example"
},
"ActiveDirectoryConfig": {
"GroupManagedServiceAccounts": [
{
"Name": "WebApp01",
"Scope": "example.com"
}
],
"HostAccountConfig": {
"PortableCcgVersion": "1",
"PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}",
"PluginInput": {
"CredentialArn": "{{arn:aws:secretsmanager:{{aws-region}}:111122223333:secret:MySecret}}"
}
}
}
}
```
**Como criar um CredSpec e fazer upload em um Amazon S3**
Você cria um CredSpec usando o módulo CredSpec PowerShell em um computador Windows que esteja associado ao domínio. Siga as etapas em [Criar uma especificação de credencial](https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts#create-a-credential-spec) no site do Microsoft Learn.
Depois de criar o arquivo de especificação da credencial, faça upload dele em um bucket do Amazon S3. Copie o arquivo CredSpec para o computador ou ambiente em que você está executando os comandos da AWS CLI.
Execute o comando AWS CLI a seguir para fazer upload do CredSpec no Amazon S3. Substitua `{{amzn-s3-demo-bucket}}` pelo nome do bucket do Amazon S3. É possível armazenar o arquivo como um objeto em qualquer bucket e local, mas deve permitir o acesso a esse bucket e ao local na política que você anexa ao perfil de execução da tarefa.
No PowerShell, use o seguinte comando:
```
$ Write-S3Object -BucketName "{{amzn-s3-demo-bucket}}" -Key "ecs-domainless-gmsa-credspec" -File "gmsa-cred-spec.json"
```
O comando da AWS CLI a seguir usa caracteres de continuação de barra invertida que são usados pelo `sh` e por shells compatíveis.
```
$ aws s3 cp gmsa-cred-spec.json \
s3://{{amzn-s3-demo-bucket/ecs-domainless-gmsa-credspec}}
```