Due to lack of time and 0-level experience in GCP, I search for help.
Task: pass metrics from GCP cluster (Prometheus) to AWS Managed Prometheus.
As far as I understand, the trust policy for AMP role should be like this:
{
"Effect": "Allow",
"Principal": {
"Federated": "accounts.google.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"accounts.google.com:oaud": <?>,
"accounts.google.com:aud": < service role that is used by cluster >,
"accounts.google.com:sub": < account from which cluster was created >
}
}
}
I don't get what is accounts.google.com:oaud. Is it something like AWS cluster oidc and where I can find it?
Related
I am trying to enable logging on the load balancers created by AWS Beanstalk using Terraform, by referring the below article,
https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/enable-access-logs.html
The article speaks about hard coding the 'elb-account-id' in the S3 policy so that the ELB has access to write logs to the bucket. Is this secure from a security standpoint, and what is this account ID?
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::elb-account-id:root"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::bucket-name/prefix/AWSLogs/your-aws-account-id/*"
}
]
}
Is there a way to replace this elb-account-id with my own account id?
I have deployed elastic beanstalk which has a role MyEBSRole in Account A. I would like to give this role access to Event Bridge in other account (Account B) (cross account). In Account B Event Bridge, I have added the following resource based policy:
{
"Sid": "mysid",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<Account-A-ID>:role/MyEBSRole"
},
"Action": ["events:PutRule", "events:ListRules", "events:DeleteRule", "events:DescribeRule", "events:DisableRule", "events:EnableRule", "events:PutTargets", "events:RemoveTargets"],
"Resource": "arn:aws:events:<Region>:<Account-B-ID>:rule/*",
"Condition": {
"StringEqualsIfExists": {
"events:creatorAccount": "${aws:PrincipalAccount}"
}
}
}
But I am getting the following exception:
An error occurred (AccessDeniedException) when calling the ListRules operation: User: arn:aws:sts::<Account-A-ID>:assumed-role/MyEBSRole/i-0b68xxxxxxx is not authorized to perform: events:ListRules on resource: arn:aws:events:<Region>:<Account-B-ID>:rule/*
If I replace the principal in resource based policy to this:
"Principal": {
"AWS": "arn:aws:iam::<Account-A-ID>:root"
}
Then I am able to get result via cloud shell, but with Elastic beanstalk it is still not working.
I also tried with arn:aws:sts::<Account-A-ID>:assumed-role/MyEBSRole/i-0b68xxxxxxx in principal but it also does not work.
Could anyone please, indicate what is wrong or missing there? Thank you.
i have eks setup and provisioned aws managed service for prometheus. Created policy with AMP full access( "aps:*") and attached that policy to role which is used by EKS.
Prometheus is installed on eks but it was not able to push metrics into Prometheus managed service.
EKS is provisioned in VPC.
Error:
ts=2021-07-07T00:43:57.951Z caller=dedupe.go:112 component=remote
level=warn remote_name=e595f3
url=http://localhost:8005/workspaces/ws-xxxx-xxxx-xxxx/api/v1/remote_write
msg="Failed to send batch, retrying" err="server returned HTTP status
502 Bad Gateway: unable to proxy request - WebIdentityErr: failed to
retrieve credentials"
ingest policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"aps:*"
],
"Resource": "*"
}
]
}
Trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::xxxxxx:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/65ETDGGHD56WTRSDGF"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/65ETDGGHD56WTRSDGF:sub": "system:serviceaccount:test-eks-prometheus:amp-iamproxy-query-service-account"
}
}
}
]
}
any help on this?
From "url=http://localhost:8005/workspaces/ws-xxxx-xxxx-xxxx/api/v1/remote_write"it looks like you are trying to use sigv4 proxy.
Prometheus now supports sigv4 natively, I'd recommend this setup to remove one component to debug the problem through
Requirement: To restrict IAM user from creating VPC with dedicated tenancy. IAM user should only be able to create VPC with default tenancy.
IAM Policy Attached to IAM User:
{
"Sid": "limitedTenancyVpc",
"Effect": "Deny",
"Action": "ec2:CreateVpc",
"Resource": "arn:aws:ec2:*:*:vpc/*",
"Condition": {
"ForAnyValue:StringNotLike": {
"ec2:Tenancy": [
"default"
]
}
}
}
I know that for VPC InstanceTenancy is keyword to be used. I tried with it in condition, however it's not working. IAM user with this policy attached is able to create VPC with dedicated tenancy.
Please suggest.
It is not possible to restrict this as there is no condition associated with ec2:CreateVPC action. See the list of available EC2 conditions keys.
However, ec2:tenancy condition is available for ec2:runInstances. So you can instead deny requests to launch instances with dedicated tenancy as a guardrail.
There are 3 different tenancy types: default, dedicated and host. Deny requests if tenancy is set to either host or dedicated.
{
"Sid": "limitedTenancyVpc",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "*",
"Condition": {
"ForAnyValue:StringEquals": {
"ec2:Tenancy": [
"host",
"dedicated"
]
}
}
}
Background
Wiring
I have an Elasticsearch cluster on AWS Elasticsearch Service. It has a Kibana endpoint enabled. Cognito provides the AWS role based on the user's group.
Cognito groups and AWS roles
The AWS role that is set to the group viewer by AWS Cognito is arn:aws:iam:123:role/kibana-viewer.
The AWS role that is set to the group admin by AWS Cognito is arn:aws:iam:123:role/kibana-admin.
Desired restriction
Only admin group should have access to a specific index pattern when using Kibana to view the data. The limited index Elasticsearch pattern is secret-*.
The viewer group should not be able to access secret-* via Kibana.
Question
How can I prevent only the role arn:aws:iam:123:role/kibana-viewer from accessing secret-* index pattern in the AWS Elasticsearch cluster?
What I have tried
First attempt
Setting the following statement in access policy:
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:123:role/kibana-viewer"
},
"Action": "es:*",
"Resource": "arn:aws:es:my-region:123:domain/my-domain/*"
}
The viewer was able to access index secret-1.
Second attempt
Setting the above Resource to arn:aws:es:my-region:123:domain/my-domain/secret-*, a viewer can't login due to:
User: x:x:x::xx:x is not authorized to perform: es:ESHttpGet
Third attempt
Setting both statements:
{
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam:123:role/kibana-viewer"
},
"Action": "es:ESHttpGet",
"Resource": "arn:aws:es:my-region:123:domain/my-domain/secret-*"
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:123:role/kibana-viewer"
},
"Action": "es:ESHttpGet",
"Resource": "arn:aws:es:my-region:123:domain/my-domain/*"
}
A viewer can login to Kibana but can't see any data due to 403 error on API call _plugin/kibana/api/saved_objects/?type=index-pattern&per_page=10000.
I was not able to solve it using AWS Elasticsearch.
However, I was able to get the desired result usin Open Distro for Elasticsearch on EC2. Also wrote a detailed blog post about it.