Question: If I add a VPC to the Lambda, does it loose access to AWS services like DynamoDB? ***
My Lambda needs to do a fetch two HTTPS services (technically one is wss). As I understand Lambdas, they can't get to anything, even AWS services unless given. The Lambda already was able to access DynamoDB tables, but I wanted to give it the REST services as well. I read somewhere that the Lambda can't really connect almost anywhere without associating it with a VPC. To do that, I added an inline policy as described at AWS Lambda:The provided execution role does not have permissions to call DescribeNetworkInterfaces on EC2
The Lambda has a custom role which has AWS Policies:
AmazonS3FullAccess
AmazonAPIGatewayInvokeFullAccess
AmazonDynamoDBFullAccess
AWSLambdaBasicExecutionRole
plus an inline policy (literally from the SO link above)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeNetworkInterfaces",
"ec2:CreateNetworkInterface",
"ec2:DeleteNetworkInterface",
"ec2:DescribeInstances",
"ec2:AttachNetworkInterface"
],
"Resource": "*"
}
]
}
As long as you configure the lambda to use a subnet in your VPC that has internet access then it will be able to reach DynamoDB just fine. I suggest you specify two subnets for high availability. If you use private subnets then you'll need to create NAT gateways so that they have internet access. Access to AWS services could get a bit more complex if you're using something like VPC endpoints, but if you're not using those in your VPC then it's not something you need to worry about.
Also, you really only need to use VPCs/Subnets with your lambda if it needs access to resources that reside within the VPC (such as an RDS cluster, or some API that is not publicly available). Otherwise, if you don't specify a vpc, your lambda will have internet access by default.
Related
I have an AWS OpenSearch cluster configured with an IAM master user role. I have an AWS Lambda which I want to be able to query both OpenSearch and other AWS services like DynamoDB. I don't want to modify the OpenSearch master user role to be able to access other AWS services - it should have zero permissions.
My current solution is letting my Lambda call assumeRole to assume the master user role before querying OpenSearch. Is this the approved way to do it? Seems like it would be more efficient not to have to do the assume role step. And it has the downside that the Lambda then has full access to OpenSearch - I would prefer to give it more granular permissions, e.g. only es:ESHttpGet.
This AWS documentation https://docs.aws.amazon.com/opensearch-service/latest/developerguide/ac.html seems to imply that you can set a resource-based access policy on domain setup which grants permissions to specific users. But I tried creating a maximally permissive policy and I still can't access the domain except as the master role. Am I misunderstanding the docs?
The permissive access policy I tried to use:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "es:*",
"Resource": "arn:aws:es:eu-west-1:REDACTED:domain/*/*"
}
]
}
I'm implementing something like that at the moment and it's not quite finished, but I am using API Gateway and a Lambda authoriser function to allow basic authentication. You could try that. The policy I have is almost the same as yours except after domain I have the name of the domain, not a star. I also have vpcs for security locked down to a cidr range.
We have AWS accounts created and managed using control tower service.
The requirement is to restrict internet access from lambda even it is not attached to any VPC.
By default lambda functions can connect to internet if it is not connected to any VPC.
How do we enforce restricting internet access to users using lambda functions ?
Lambda is always in a VPC,just when you don't specify a VPC it's assigned to default one which has internet access configured.
Create a new VPC, by default it won't have internet access. And assign your functions to it.
We have addressed this requirement by creating a service control policy with below statements and attached to the OU.
It enforces the users to select a VPC, subnet and security group while creating/updating the lambda function. With this you can make sure the lambda functions are always under your VPC.
Ref: https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html#vpc-conditions
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "EnforceVPCFunction",
"Action": [
"lambda:CreateFunction",
"lambda:UpdateFunctionConfiguration"
],
"Effect": "Deny",
"Resource": "*",
"Condition": {
"Null": {
"lambda:VpcIds": "true"
}
}
}
]
}
Refer the above AWS documentation to find the policy statements to enable restriction at different levels like subnet, Security group and VPC.
I have this policy rule in my S3 bucket called aws-coes:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AddPerm",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::aws-coes/*"
],
"Condition": {
"StringEquals": {
"aws:sourceVpc": "vpc-foo"
}
}
}
]
}
I was expecting that only the machines under my VPC "vpc-foo" could get the resources from my bucket, but no machine can get anything.
Did I do something wrong here?
Also I follow the steps of this post but nothing https://blog.adminfactory.net/allow-access-to-s3-bucket-only-from-ec2-instances.html
I once had a similar issue. The following comes into my mind:
The policy looks good. The s3:GetObject action does not need to reference the bucket as resource. A wildcard path pointing at objects is sufficient. The policy examples [1] in the docs clearly state that fact.
You must use the vpc id as value for the aws:sourceVpc condition. Just mentioning it to make sure that you are not using the VPC ARN accidentally. [2]
What is also interesting, is that people most likely use the aws:sourceVpc condition to restrict access (i.e. a deny policy) - not to whitelist traffic. This is most likely not a functional issue, but I want to mention it nonetheless. From a security perspective it is probably safer to restrict access to the S3 bucket (as described in the aws docs) and attaching an EC2 instance role which grants access to the S3 bucket. This way, all EC2 instances within a particular VPC are able to access an S3 bucket, but other (possibly malicious) network entities are not.
I would double check if the requests from your EC2 instance are really routed through the VPC endpoint. As mentioned by the docs [3], it is crucial for the traffic to originate from an AWS VPC endpoint. This is accomplished inside the VPC by routing the traffic over a dedicated route inside the AWS network instead of the Internet Gateway. Could you please double check that you added the VPC endpoint to your route table correctly? One way you could check this is to make a public S3 bucket and access it from the EC2 instance. Subsequently, attach a vpc endpoint policy which denies all S3 traffic. Then, try to access the S3 bucket from your EC2 instance again. If the second time, access is denied, you know that probably the VPC endpoint is used and traffic is routed correctly inside the VPC.
Depending on the size of your organization there might be other IAM controls in place which deny the access. This is probably not an issue, but it might be worth checking if your company uses AWS Organizations and has an SCP which denies access. Also check, if there is no explizit deny, e.g. for your EC2 instance role. Take a look at the IAM evaluation logic [4] for more information.
You did not mention in your question if you are using one single AWS account or if you are in a multi-account scenario, e.g. an S3 bucket in account A and a VPC in account B. Iff this is the case, please check out the docs in [5], since it changes the policy evaluation logic when context authority and bucket owner differ. Using the aws:sourceVpc condition cross-account is probably not even possible. [6]
I hope some of these points are helpful to track the issue down.
References
[1] https://docs.aws.amazon.com/AmazonS3/latest/dev/example-policies-s3.html#iam-policy-ex0
[2] https://docs.aws.amazon.com/AmazonS3/latest/dev/example-bucket-policies-vpc-endpoint.html#example-bucket-policies-restrict-access-vpc
[3] https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcevpc
[4] https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#policy-eval-denyallow
[5] https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-auth-workflow-object-operation.html
[6] https://stackoverflow.com/a/52517646/10473469
FYI, internally in the EC2-->S3 networking stack there are certain edge cases where the SourceVPC header is not passed on requests to S3, in those cases you'll need to use a VPC endpoint condition instead.
Source (I used to do a lot of S3 support at AWS).
I have created a policy for restricting access of a user to a single instance as:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1392113879000",
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": [
"arn:aws:ec2:us-east-1:account:instance/instance_id"
]
}
]
}
But I am getting this error:
You are not authorized to describe Running Instances
You are not authorized to describe Elastic IPs
You are not authorized to describe Volumes
You are not authorized to describe Snapshots
You are not authorized to describe Key Pairs
You are not authorized to describe Load Balancers
You are not authorized to describe Placement Groups
You are not authorized to describe Security Groups
I cant see the instance in the console. If i cant implement this thing then what is the use of policies!!
Im stuck please help
from iam-policies-for-amazon-ec2
Currently, not all API actions support individual ARNs; we'll add
support for additional API actions and ARNs for additional Amazon EC2
resources later. For information about which ARNs you can use with
which Amazon EC2 API actions, as well as supported condition keys for
each ARN, see Supported Resources and Conditions for Amazon EC2 API
Actions.
So, wiritng ec2:* is not going to help you. Instead, you should provide exact API actions that you wish to grant to this user.
Also, quoting from the same link referred above:
To specify all resources, or if a specific API action does not support ARNs, use the * wildcard in the Resource element as follows:
Assigning restrictive EC2 IAM polices is a bit complicated. You may want to read above referred link in detail as well as this link.
Check your region. Your policy uses US-East-1, but where are your instances? US-West-2?
I have read the AWS documentation and it wasn't helpful... at least not for me. I have read about IAM and the user policy on the EC2.
I want to make users have full access/(or just some actions allowed) only on ONE ec2 instance.
The region I'm using is eu-west-1(Ireland). I made this policy:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "arn:aws:ec2:eu-west-1:ACCOUNT_ID:instance/INSTANCE_ID"
}]
}
and when I login as the user, I see that I'm not authorized:
You are not authorized to describe Running Instances
You are not authorized to describe Elastic IPs
You are not authorized to describe Volumes
You are not authorized to describe Snapshots
You are not authorized to describe Key Pairs
You are not authorized to describe Load Balancers
You are not authorized to describe Placement Groups
You are not authorized to describe Security Groups
If I apply the following policy for the resource attribute:
"Resource": "arn:aws:ec2:*"
it's Ok but it's not what I need because users have access on all EC2 instances.
I want to know if this is a bug of AWS or there are problems with eu-west-1 region or this policy isn't supported already? Or maybe I'm wrong, if so, please help me how to do
The recently introduced Resource-Level Permissions for EC2 and RDS Resources are not yet available for all API actions, but AWS is gradually adding more, see this note from Amazon Resource Names for Amazon EC2:
Important Currently, not all API actions support individual ARNs; we'll add support for additional API actions and ARNs for additional
Amazon EC2 resources later. For information about which ARNs you can
use with which Amazon EC2 API actions, as well as supported condition
keys for each ARN, see Supported Resources and Conditions for Amazon
EC2 API Actions.
You will find that all ec2:Describe* actions are indeed absent still from Supported Resources and Conditions for Amazon EC2 API Actions at the time of this writing.
See also Granting IAM Users Required Permissions for Amazon EC2 Resources for a concise summary of the above and details on the ARNs and Amazon EC2 condition keys that you can use in an IAM policy statement to grant users permission to create or modify particular Amazon EC2 resources - this page also mentions that AWS will add support for additional actions, ARNs, and condition keys in 2014.
Possible Workaround/Alternative
Instead of or in addition to constraining access on the individual resource level, you might want to check into (also) using Conditions combined with Policy Variables, insofar ec2:Regionis one of the supported Condition Keys for Amazon EC2 - you might combine your policy with one that specifically handles Describe* actions, e.g. something like this (untested):
{
"Statement": [
{
"Action": [
"ec2:Describe*"
],
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:Region": "eu-west-1"
}
}
}
]
}
Please note that this would still allow the user to see all instances in eu-west-1, even though your original policy fragment would prevent all API actions that already support resource level permissions (e.g instance creation/termination etc.).
I've outlined yet another possible approach in section Partial Workaround within my related answer to How to hide instances in EC2 based on tag - using IAM?.
Good Luck!