Dê à aplicação acesso aos seus relatórios

Introdução

Uma aplicação em execução precisa ler um relatório privado. Você conectará uma função IAM e um perfil de instância por meio de referências do Terraform, concederá acesso ao objeto pretendido e testará as solicitações efetivas da aplicação antes e depois da remoção da permissão.

Este laboratório pressupõe conhecimentos de referências do Terraform e implantação EC2, além de confiança de funções AWS, perfis de instância e permissões S3 com escopo restrito. Um novo ambiente fornece a aplicação em execução, sua rede, um bucket privado de relatórios e uma aplicação de referência não relacionada. Você manterá os dados fornecidos e o ambiente de referência intactos.

Relação com certificações

Visão geral do laboratório

Dê à aplicação em execução uma identidade de função

Nesta etapa, você definirá uma função para EC2 e um perfil de instância, anexará o perfil à aplicação fornecida e observará a identidade efetiva da carga de trabalho.

O AWS View acima exibe os mesmos recursos consultados no Terminal. Seu seletor Request path pode solicitar a verificação de saúde da aplicação, a identidade da carga de trabalho ou qualquer um dos dois objetos privados. O Terminal usa a identidade preparada do operador; a aplicação usa sua própria função de instância. Uma consulta bem-sucedida do operador não comprova que a aplicação tem permissão.

Inspecione o diretório raiz preparado e registre o ID da instância:

cd /home/labex/project/application-reports
cat terraform.tfvars.json
cat application.tf
terraform state list
INSTANCE_ID=$(terraform output -raw instance_id)
echo "$INSTANCE_ID"
REPORT_BUCKET=$(terraform output -raw report_bucket)
echo "$REPORT_BUCKET"

O estado existente gerencia a instância da aplicação. A rede, a AMI, o bucket e a aplicação de referência foram fornecidos separadamente. User Data já aponta a aplicação para report.csv no bucket preparado, mas não contém nenhuma chave de acesso.

No AWS View, selecione application-server, User · 198.51.100.10, Application · 8081 e Health e clique em Send request. Espere Connected · 200 e Report application. Escolha Private report e envie novamente. A aplicação ainda não consegue lê-lo e informa Connected · 503 com Application storage unavailable: a aplicação HTTP está acessível, mas não tem credenciais da carga de trabalho.

A política de confiança de uma função IAM controla quem pode assumi-la. Um perfil de instância conecta a função ao EC2. Nenhum desses objetos, por si só, concede permissão para ler um objeto S3. Crie esses dois recursos:

cat > identity.tf <<'HCL'
resource "aws_iam_role" "reports" {
  name = "tf-report-reader"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
      Action = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_instance_profile" "reports" {
  name = "tf-report-reader"
  role = aws_iam_role.reports.name
}
HCL
sed -i '/vpc_security_group_ids/a\  iam_instance_profile = aws_iam_instance_profile.reports.name' application.tf
terraform fmt
terraform validate
terraform plan

O comando sed insere o atributo de perfil de instância após o atributo existente de grupo de segurança. Sua referência a recurso conecta a instância em execução ao perfil, que faz referência à função. Revise o plano: crie a função e o perfil e atualize a associação da instância existente, sem substituir a instância nem alterar User Data.

Aplique e digite yes:

terraform apply

Inspecione a associação e o perfil nativos:

aws ec2 \
  describe-iam-instance-profile-associations \
  --filters "Name=instance-id,Values=$INSTANCE_ID" \
  --query 'IamInstanceProfileAssociations[].{Instance:InstanceId,State:State,Profile:IamInstanceProfile.Arn}'
aws iam \
  get-instance-profile \
  --instance-profile-name tf-report-reader \
  --query 'InstanceProfile.{Name:InstanceProfileName,Roles:Roles[].RoleName}'

No AWS View, escolha Workload identity para application-server e envie uma solicitação. Espere Connected · 200 e um ARN contendo assumed-role/tf-report-reader/. Isso vem do STS dentro da instância convidada, usando credenciais temporárias da função, e não do operador do Terminal.

Escolha Private report e envie novamente. Espere Connected · 403 e Access denied. A identidade de função agora funciona, mas ainda não há permissão de leitura do objeto. Esta é uma falha intencional de autorização.

Conceda acesso apenas ao relatório pretendido

Nesta etapa, você concederá à função da aplicação uma permissão de leitura de objeto e testará tanto o relatório permitido quanto um objeto privado não relacionado.

A política de permissões de uma função determina o que sua sessão pode fazer. Use uma política de identidade que permita s3:GetObject para o ARN exato de report.csv. O nome do bucket vem da entrada fornecida; a função vem da referência a recurso. Nenhuma credencial estática deve ser colocada em User Data.

cat > permissions.tf <<'HCL'
resource "aws_iam_role_policy" "report" {
  name = "ReadApplicationReport"
  role = aws_iam_role.reports.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = ["s3:GetObject"]
      Resource = ["arn:aws:s3:::${var.report_bucket}/report.csv"]
    }]
  })
}
HCL
terraform fmt
terraform validate
terraform plan

O plano adiciona uma política. Ele não deve substituir a aplicação nem criar um novo bucket. Aplique e digite yes:

terraform apply

No AWS View, mantenha application-server, User e a porta 8081 selecionados. Escolha Private report e envie uma solicitação. Espere Connected · 200, com o relatório:

period,total
Q1,320

Escolha Unrelated private object e envie outra solicitação. Espere Connected · 403 e Access denied. A aplicação pode ler seu próprio relatório, enquanto private.csv permanece fora da concessão. Esse 403 é um resultado efetivo de autorização do S3 retornado pela aplicação alcançada, não uma falha de conexão de rede.

Volte para Workload identity e envie novamente. Seu ARN ainda deve identificar a função da carga de trabalho. Confirme a convergência:

terraform plan

Espere No changes.

Revogue a permissão e teste o efeito efetivo

Nesta etapa, você removerá apenas a política de leitura e demonstrará que uma aplicação em execução com uma identidade de função válida deixa de ter acesso ao relatório.

Remover a permissão é diferente de desanexar o perfil ou parar a instância. Mantenha a função e o perfil, remova a configuração do recurso de política e revise a exclusão:

rm permissions.tf
terraform plan

Espere a destruição da política de leitura, sem substituição da instância. Aplique e digite yes:

terraform apply

Leia os nomes das políticas inline restantes de forma independente:

aws iam \
  list-role-policies \
  --role-name tf-report-reader \
  --query PolicyNames

Espere []. No AWS View, envie Workload identity para a aplicação. Ela ainda retorna Connected · 200 com o mesmo nome de função. Em seguida, envie solicitações Private report e Unrelated private object. Ambas devem retornar Connected · 403 e Access denied. A leitura negada comprova que a remoção da permissão afeta solicitações efetivas da carga de trabalho, mesmo que a aplicação e sua associação de função ainda existam.

terraform plan

Espere No changes.

Remova os recursos gerenciados e preserve os dados fornecidos

Nesta etapa, você removerá a instância, o perfil e a função gerenciados, preservando o bucket externo de relatórios, seus objetos e o ambiente de referência.

A política já foi removida. Revise o escopo restante de exclusão:

terraform plan -destroy

Espere os três recursos gerenciados: a instância da aplicação, o perfil de instância e a função IAM. Em seguida, destrua-os e digite yes:

terraform destroy

A mesma instância deve constar como encerrada na consulta nativa:

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{ID:InstanceId,State:State.Name}'
terraform state list

Espere terminated e nenhum recurso gerenciado no estado. Consulte as listas de funções e perfis usando os nomes exatos; listas vazias bem-sucedidas estabelecem a ausência sem tratar uma falha de autenticação como limpeza:

aws iam list-roles --query "Roles[?RoleName=='tf-report-reader'].RoleName"
aws iam list-instance-profiles --query "InstanceProfiles[?InstanceProfileName=='tf-report-reader'].InstanceProfileName"

Ambas retornam []. O bucket foi fornecido fora deste estado. Use o operador do Terminal para ler os dois objetos preservados e inspecionar seus bytes. Essas leituras do operador verificam a preservação; o acesso restrito da aplicação foi testado separadamente por meio de sua função.

aws s3api get-object --bucket "$REPORT_BUCKET" --key report.csv /tmp/retained-report.csv
cat /tmp/retained-report.csv
aws s3api get-object --bucket "$REPORT_BUCKET" --key private.csv /tmp/retained-private.csv
cat /tmp/retained-private.csv

O relatório continua sendo period,total / Q1,320; o objeto não relacionado continua sendo private,retained. No AWS View, selecione reference-server, User, Application · 8081 e Health e envie uma solicitação. Espere Connected · 200 e Reference application.

Mantenha os arquivos do Terraform para revisão. Um plano comum posterior proporia recriar os recursos da configuração restante; uma destruição bem-sucedida não exige excluir essa configuração.

Resumo

Você conectou a instância de uma aplicação a uma função por meio de referências do Terraform, distinguiu identidade de função de permissão de objeto e testou tanto uma leitura bem-sucedida de relatório privado quanto a recusa de um objeto não relacionado. Em seguida, revogou a concessão, observou a falha efetiva de autorização e removeu os recursos gerenciados, preservando os dados fornecidos e a aplicação de referência.