Da a la aplicación acceso a sus informes

Introducción

Una aplicación en ejecución necesita leer un informe privado. Conectarás un rol IAM y un perfil de instancia mediante referencias de Terraform, concederás acceso al objeto previsto y probarás las solicitudes reales de la aplicación antes y después de eliminar el permiso.

Este laboratorio presupone conocimientos sobre referencias de Terraform y despliegue de EC2, además de confianza de roles de AWS, perfiles de instancia y permisos de S3 de alcance limitado. Un entorno nuevo proporciona la aplicación en ejecución, su red, un bucket privado de informes y una aplicación de referencia ajena. Mantendrás intactos los datos suministrados y el entorno de referencia.

Relación con las certificaciones

Vista general del laboratorio

Asigna una identidad de rol a la aplicación en ejecución

En este paso, definirás un rol de EC2 y un perfil de instancia, asociarás el perfil a la aplicación suministrada y observarás su identidad efectiva de carga de trabajo.

AWS View, en la parte superior, muestra los mismos recursos que se consultan en Terminal. Su selector Request path permite solicitar el estado de salud de la aplicación, la identidad de la carga de trabajo o cualquiera de los dos objetos privados. Terminal usa la identidad del operador preparada; la aplicación usa su propio rol de instancia. Una consulta correcta del operador no demuestra que la aplicación tenga permiso.

Inspecciona la configuración raíz preparada y registra el ID de la instancia:

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"

El estado existente gestiona la instancia de aplicación. La red, la AMI, el bucket y la aplicación de referencia se suministraron por separado. User Data ya apunta la aplicación a report.csv en el bucket preparado, pero no contiene ninguna clave de acceso.

En AWS View, selecciona application-server, User · 198.51.100.10, Application · 8081 y Health y haz clic en Send request. Debes ver Connected · 200 y Report application. Elige Private report y vuelve a enviar. La aplicación todavía no puede leerlo y muestra Connected · 503 con Application storage unavailable: la aplicación HTTP es accesible, pero no tiene credenciales de carga de trabajo.

La política de confianza de un rol IAM controla quién puede asumirlo. Un perfil de instancia conecta el rol con EC2. Ninguno de los dos objetos, por sí solo, concede permiso para leer un objeto de S3. Crea esos dos 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

El comando sed inserta el atributo del perfil de instancia después del atributo existente del grupo de seguridad. Su referencia a un recurso conecta la instancia en ejecución con el perfil, que hace referencia al rol. Revisa el plan: debe crear el rol y el perfil y actualizar la asociación de la instancia existente, sin sustituir la instancia ni cambiar User Data.

Aplica los cambios e introduce yes:

terraform apply

Inspecciona la asociación y el 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}'

En AWS View, elige Workload identity para application-server y envía una solicitud. Debes ver Connected · 200 y un ARN que contenga assumed-role/tf-report-reader/. Procede de STS dentro de la instancia usando credenciales temporales del rol, no del operador de Terminal.

Elige Private report y vuelve a enviar. Debes ver Connected · 403 y Access denied. La identidad del rol ya funciona, pero todavía no hay permiso de lectura de objetos. Este es un fallo de autorización intencionado.

Concede acceso únicamente al informe previsto

En este paso, concederás al rol de la aplicación un permiso de lectura de objeto y probarás tanto el informe permitido como un objeto privado ajeno.

La política de permisos de un rol determina qué puede hacer su sesión. Usa una política de identidad que permita s3:GetObject para el ARN exacto de report.csv. El nombre del bucket procede de la entrada suministrada; el rol procede de la referencia al recurso. No debe incluirse ninguna credencial estática en 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

El plan añade una política. No debe sustituir la aplicación ni crear un bucket nuevo. Aplica los cambios e introduce yes:

terraform apply

En AWS View, mantén seleccionados application-server, User y el puerto 8081. Elige Private report y envía una solicitud. Debes ver Connected · 200, con el informe:

period,total
Q1,320

Elige Unrelated private object y envía otra solicitud. Debes ver Connected · 403 y Access denied. La aplicación puede leer su propio informe, mientras private.csv sigue fuera del permiso. Este 403 es un resultado real de autorización de S3 devuelto por la aplicación a la que se ha llegado, no una conexión de red fallida.

Vuelve a Workload identity y envía de nuevo. Su ARN debe seguir identificando el rol de la carga de trabajo. Confirma la convergencia:

terraform plan

Debes ver No changes.

Revoca el permiso y prueba su efecto real

En este paso, eliminarás únicamente la política de lectura y demostrarás que una aplicación en ejecución con una identidad de rol válida ya no tiene acceso al informe.

Eliminar un permiso es distinto de desasociar el perfil o detener la instancia. Conserva el rol y el perfil, elimina la configuración del recurso de política y revisa después la eliminación:

rm permissions.tf
terraform plan

Debe destruirse la política de lectura sin sustituir la instancia. Aplica los cambios e introduce yes:

terraform apply

Lee los nombres de las políticas en línea restantes de forma independiente:

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

Debes ver []. En AWS View, envía Workload identity para la aplicación. Sigue devolviendo Connected · 200 con el mismo nombre de rol. Después, envía solicitudes Private report y Unrelated private object. Ambas deben devolver Connected · 403 y Access denied. La lectura denegada demuestra que eliminar el permiso afecta a las solicitudes reales de la carga de trabajo, aunque la aplicación y su asociación de rol sigan existiendo.

terraform plan

Debes ver No changes.

Elimina los recursos gestionados y conserva los datos suministrados

En este paso, eliminarás la instancia, el perfil y el rol gestionados conservando el bucket externo de informes, sus objetos y el entorno de referencia.

La política ya se ha eliminado. Revisa el alcance de la eliminación restante:

terraform plan -destroy

Deben aparecer los tres recursos gestionados: la instancia de aplicación, el perfil de instancia y el rol IAM. Después, destrúyelos e introduce yes:

terraform destroy

La misma instancia debe figurar como terminada en la consulta nativa:

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

Debes ver terminated y ningún recurso gestionado en el estado. Consulta las listas de roles y perfiles usando los nombres exactos; unas listas vacías obtenidas correctamente establecen su ausencia, sin considerar un fallo de autenticación como una limpieza:

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

Ambas devuelven []. El bucket se suministró fuera de este estado. Usa el operador de Terminal para leer ambos objetos conservados e inspeccionar sus bytes. Estas lecturas del operador comprueban la conservación; el acceso restringido de la aplicación se probó por separado a través de su rol.

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

El informe sigue siendo period,total / Q1,320; el objeto ajeno sigue siendo private,retained. En AWS View, selecciona reference-server, User, Application · 8081 y Health y envía una solicitud. Debes ver Connected · 200 y Reference application.

Conserva los archivos de Terraform para revisarlos. Un plan ordinario posterior propondría volver a crear los recursos de la configuración restante; una destrucción correcta no requiere eliminar esa configuración.

Resumen

Has conectado la instancia de una aplicación con un rol mediante referencias de Terraform, distinguido la identidad del rol del permiso sobre objetos y probado tanto una lectura correcta del informe privado como la denegación de un objeto ajeno. Después has revocado el permiso, observado el fallo real de autorización y eliminado los recursos gestionados conservando los datos suministrados y la aplicación de referencia.