Reputation: 491
On ElasticBeanstalk, under Logs section, when I access this tab I immediately get an error, An error occurred retrieving logs: Access Denied
.
If I click on request latest 100 lines of log I get another error on EB events.
Failed retrieveEnvironmentInfo activity. Reason: Access Denied
On events log I get two errors:
ERROR Failed retrieveEnvironmentInfo activity. Reason: Access Denied
INFO [Instance: i-0aa53b9c5f88fe09b] Successfully finished tailing 36 log(s)
INFO Pulled logs for environment instances.
ERROR Service:Amazon S3, Message:Access Denied
My role policy atm allow me for these operations:
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:*",
"cloudformation:*",
"cloudwatch:*",
"dynamodb:*",
"ec2:Describe*",
"ec2:Get*",
"ec2messages:Get*",
"elasticbeanstalk:*",
"iam:*",
"kms:ListAliases",
"lambda:Get*",
"lambda:List*",
"logs:Describe*",
"logs:FilterLogEvents",
"logs:Get*",
"logs:List*",
"logs:ListTagsLogGroup",
"logs:TestMetricFilter",
"sdb:Get*",
"s3:Get*",
"s3:List*",
"ses:*",
"sns:*",
"sqs:*"
],
"Resource": "*"
},
{
"Effect": "Deny",
"Action": [
"cloudformation:DeleteStack",
"dynamodb:DeleteTable",
"elasticbeanstalk:DeleteEnvironment*",
"elasticbeanstalk:DeleteApplication",
"iam:Create*",
"iam:Delete*",
"iam:Remove*",
"s3:DeleteBucket",
"sqs:DeleteQueue"
],
"Resource": "*"
}
I also have my EB policy.
"autoscaling:Describe*",
"autoscaling:SuspendProcesses",
"autoscaling:ResumeProcesses",
"cloudwatch:*",
"cloudformation:List*",
"cloudformation:Describe*",
"cloudformation:Get*",
"elasticbeanstalk:*",
"elasticfilesystem:Describe*",
"elasticloadbalancing:DescribeLoadBalancers",
"elasticloadbalancing:RegisterInstancesWithLoadBalancer",
"health:Describe*",
"health:Get*",
"health:List*",
"lambda:UpdateFunctionCode",
"lambda:CreateAlias",
"logs:*",
"s3:Get*",
"s3:List*",
"s3:Head*",
"s3:Put*",
"s3:DeleteObject"
],
"Effect": "Allow",
"Resource": "*"
So, when you use ELB and try to see logs, does it use the user role policy or the service policy to check for permission? it seems pretty weird.
Upvotes: 0
Views: 2460
Reputation: 3
Using "s3:*" is too permissive. In addition to the other elastic beanstalk permissions, I found that these s3 permission were sufficient to be able to pull logs.
It not the minimum set of s3 permission that can be used but it's certainly more secure than "s3:*".
{
"Effect": "Allow",
"Action": [
"s3:Get*",
"s3:List*",
"s3:HeadBucket",
"s3:HeadObject",
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": [
"arn:aws:s3:::elasticbeanstalk-*",
"arn:aws:s3:::elasticbeanstalk-*/*"
]
}
Upvotes: 0
Reputation: 159
I was having a similar issue and was able to solve it by adding the following to my policy.
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::elasticbeanstalk-*"
}
Not quite sure all that is done in the elasticbeanstalk s3 bucket, but this covered it. Here's my full policy that allowed me to pull beanstalk logs.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticbeanstalk:List*",
"elasticbeanstalk:Describe*",
"elasticbeanstalk:Describe*",
"elasticbeanstalk:Request*",
"elasticbeanstalk:Retrieve*",
"ec2:Describe*",
"ec2:Get*",
"cloudformation:Describe*",
"cloudformation:List*",
"cloudformation:Get*",
"autoscaling:Describe*",
"elasticloadbalancing:Describe*",
"s3:Head*",
"s3:List*",
"s3:Get*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "arn:aws:s3:::elasticbeanstalk-*"
}
]
}
Upvotes: 4