Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not authorized to perform logs:CreateLogStream on resource #8

Closed
Prophecy67 opened this issue Aug 18, 2020 · 4 comments · Fixed by #10
Closed

Not authorized to perform logs:CreateLogStream on resource #8

Prophecy67 opened this issue Aug 18, 2020 · 4 comments · Fixed by #10
Assignees

Comments

@Prophecy67
Copy link
Contributor

Prophecy67 commented Aug 18, 2020

Related to but moved in to an issue as well:

e6acfbd#r41559321

The LogStreams seem to run in to issues when the resources are created, effectively not having the required permissions to PutLogEvents on the LogStreams, and where LogStreams are also not able to be created on the LogGroup. It did work before, but for a reason or another the wildcards are getting removed, and this effectively wrecks the logging, and thus containers as they aren't able to log with the error of:

...is not authorized to perform: logs:CreateLogStream on resource:...

CreateLogStream work on the LogGroup as supplied, but the PutlogEvents need to be supplied to each and every LogStream, and I think this is where everything goes wrong in the policy

So it should be ${var.cloudwatch_log_group_arn}:* instead of without the wildcard. if I am not mistaken.

@k-k
Copy link
Member

k-k commented Aug 18, 2020

Hey @Prophecy67 - yeah, I actually just ran into this at the end of last week and I'm a bit confused by the behavior. As you noticed, this had been working previously. I still needed to look into where this came from - maybe AWS Provider version difference?

As an example:

resource aws_cloudwatch_log_group logs {
  name = "some-log-group"
  tags   = local.tags
}

module service {
  source  = "terra-mod/ecs-service/aws"
  version = "~> 3.1"

  // ... other stuff

  cloudwatch_log_group_arn = aws_cloudwatch_log_group.logs.arn
}

This would produce the behavior you're seeing, though, I have working examples of doing exactly this in other places. In the same project, I tried referring to an existing log group via a data source and doing:

module service {
  source  = "terra-mod/ecs-service/aws"
  version = "~> 3.1"

  // ... other stuff

  cloudwatch_log_group_arn = data.aws_cloudwatch_log_group.existing_logs.arn
}

That worked properly and the resultant policy had the ARN suffixed with :*. So I just need to figure out why it's intermittent.

@Prophecy67
Copy link
Contributor Author

I haven't been able to figure it out yet either. Terraform console at least outputs the following in terms of the ARN, where no :* is suffixed at all. I've tried with previous Terraform versions and other version pins on the provider modules to no avail. All end up with this:

terraform console
> aws_cloudwatch_log_group.REDACTED.*
[
  {
    "arn" = "arn:aws:logs:eu-central-1:REDACTED:log-group:ecs-REDACTED-log-group"
    "id" = "ecs-REDACTED-log-group"
    "kms_key_id" = ""
    "name" = "ecs-REDACTED-log-group"
    "retention_in_days" = 1
    "tags" = {}
  },
]

@k-k
Copy link
Member

k-k commented Aug 28, 2020

@Prophecy67 I had a colleague share this with me, looks like the breaking change is here: hashicorp/terraform-provider-aws#14214

I'll try to implement a work around tonight

@k-k k-k self-assigned this Aug 28, 2020
@Prophecy67
Copy link
Contributor Author

Hey @kmfk Cool. Anxiously awaiting the fix; comments however outline it as well to fix it with an additional suffix in the code:

hashicorp/terraform-provider-aws#14214 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants