Seguí la primera respuesta en esta publicación en StackOverflow pero obtengo este error:
Error al configurar los atributos de LB: solicitud de configuración no válida: acceso denegado para el depósito: myproject-log. Verifique el código de estado de permiso de S3bucket: 400
Este es mi código:
cubo_s3
data "aws_elb_service_account" "main" {} resource "aws_s3_bucket" "bucket_log" { bucket = "${var.project}-log" acl = "log-delivery-write" policy = <<POLICY { "Id": "Policy", "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:PutObject" ], "Effect": "Allow", "Resource": "arn:aws:s3:::${var.project}-log/AWSLogs/*", "Principal": { "AWS": [ "${data.aws_elb_service_account.main.arn}" ] } } ] } POLICY }equilibrador de carga
resource "aws_lb" "vm_stage" { name = "${var.project}-lb-stg" internal = false load_balancer_type = "application" subnets = [aws_subnet.subnet_1.id, aws_subnet.subnet_2.id, aws_subnet.subnet_3.id] security_groups = [aws_security_group.elb_project_stg.id] access_logs { bucket = aws_s3_bucket.bucket_log.id prefix = "lb-stg" enabled = true } tags = { Name = "${var.project}-lb-stg" } }Solo voy a dejar esto aquí ya que esta cruz se aplica a otra pregunta que se hizo.
Me tomó un tiempo darme cuenta, pero el depósito S3 tiene dos requisitos según la documentación:
Fuente: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html
Si bien parece que se trata de un problema de permisos con el mensaje de error dado, en realidad puede ser un problema con el depósito que tiene el tipo de cifrado incorrecto. En mi caso, el problema era que mi balde no estaba cifrado.
Actualicé el depósito al cifrado SSE-S3 y ya no recibí el error:
resource "aws_s3_bucket" "s3_access_logs_bucket" { bucket = var.access_logs_bucket_name acl = "private" server_side_encryption_configuration { rule { apply_server_side_encryption_by_default { sse_algorithm = "AES256" } } } versioning { enabled = true } }Y solo porque, aquí está la política que usé:
data "aws_elb_service_account" "main" {} data "aws_iam_policy_document" "s3_lb_write" { statement { principals { identifiers = ["${data.aws_elb_service_account.main.arn}"] type = "AWS" } actions = ["s3:PutObject"] resources = [ "${aws_s3_bucket.s3_access_logs_bucket.arn}/*" ] } } resource "aws_s3_bucket_policy" "load_balancer_access_logs_bucket_policy" { bucket = aws_s3_bucket.s3_access_logs_bucket.id policy = data.aws_iam_policy_document.s3_lb_write.json }https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html
Consulte los documentos anteriores y cambie la política de iam de su depósito para reflejar lo que establece la documentación. El registro en realidad lo realiza AWS y no sus roles o usuarios de IAM. Por lo tanto, debe otorgar permiso a ÅWS para hacer esto. Es por eso que los documentos muestran declaraciones en la política que especifican el principal de delivery.logs.amazonaws.com . Ese principal es el servicio de registro de AWS. Aunque su depósito está alojado en AWS, no se otorgan acceso a su depósito de forma predeterminada. Debe otorgar explícitamente acceso a AWS si desea que sus servicios funcionen.
Según esta publicación , pude resolver este problema al deshabilitar KMS y usar SSE-S3 para el cifrado de depósitos. Además, hay permisos adicionales enumerados en los documentos de AWS.