I have functions deployed in vpc which doesn't have nat gateway/ internet access.
Goal: Send email through SES from this function (in vpc)
I have tried using public private subnet with nat gateway to send emails and it works fine. But i am trying to use it vi VPC endpoint. i have created an email vpc endpoint but not sure how to configure it in serverless.yml. Have tried setting up configs as said in
https://www.serverless.com/framework/docs/providers/aws/guide/serverless.yml/
but nothing working because there is no mention for ses.
You need the following configuration so that CloudFormation creates the resource. (Note the variables in brackets)
resources:
Resources:
VPCEndpointForSES:
Type: AWS::EC2::VPCEndpoint
Properties:
PrivateDnsEnabled: True
SecurityGroupIds:
- <ID of the VPC Security Group>
ServiceName: 'com.amazonaws.<AWS Region String>.email-smtp'
SubnetIds:
- <Subnet of your VPC>
- <Subnet of your VPC>
- <Subnet of your VPC>
VpcEndpointType: Interface
VpcId: <ID of your VPC>
You must use the AWS SES SMTP endpoint because AWS does not support VPC private endpoint for AWS SES API.
Guidance for configuration AWS SES SMTP with private VPC endpoint:
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-email-set-up-vpc-endpoints.html
List of available AWS services that integrate with AWS PrivateLink (or private VPC endpoint can be created):
https://docs.aws.amazon.com/vpc/latest/privatelink/integrated-services-vpce-list.html
Have you looked at AWS PrivateLink for VPC Endpoints?
You won't need to set up an Internet gateway, NAT device, VPN connection, or AWS Direct Connect connection. Your VPC can communicate with AWS SES within the Amazon network using AWS PrivateLink.
Note that VPC Endpoints currently do not support cross-region requests—ensure that you create your endpoint in the same region in which you plan to issue your API calls to Amazon SES.
You will need to create a security group and a VPC Interface Point. There's a step by step example here
Additional Resources: AWS PrivateLink Interface Endpoints
Related
I have a rails application that uses elasticsearch via the gem 'elasticsearch-rails', '~> 7.2.0'. Elasticsearch is hosted on a difference ec2 instance than the rails application. Both EC2 instances reside in the same VPC and Subnet but, have their own security groups and have restrictive inbound and outbound rules that allow them to communicate with each other (the elasticsearch instance can only receive traffic from the application instance).
The elasticsearch cluster (single node) is not currently configured to use TLS, SSL, or Authentication. Is it correct to assume that the elasticsearch cluster is secure due to the security group? I do however understand that if the application server is compromised then actor will have unlimited access to the elasticsearch cluster. Is it also correct to assume that the communication between the two instances are secure and not susceptible to interception, due to them sharing a VPC and Subnet?
Quick Question, i am trying to configure a cloudrun service to be connected using AlloyDB on GCP.
The problem here is AlloyDB is in a different region than the others services, in this case central1, and services east1.
Is there any way to do the pairing between them?
Thanks in advance,
There is no connectivity issue. You use a serverless VPC connector to bridge the serverless world (where your Cloud Run live) with your VPC. Therefore, with default configuration, all the traffic going to a private IP will arrive in your VPC.
Then you have your AlloyDB peered with your VPC also. Because the VPC is global, as long as you are in the VPC (AlloyDB or Cloud Run), any service can reach any resources, whatever their location.
In fact, your main concern should be the latency and the egress cost.
Have a Cloud Run for Anthos set up with default configuration, istio-ingress as a gateway and couple of services. Cannot find any docs on how to connect Cloud CDN with this setup.
Does anybody have some experience with that?
Cloud CDN content delivery network works with HTTP(S) load balancing to deliver content to your users1. As Istio ingress works with Network load balancer instead, so it cannot be used with Cloud CDN.
Alternatively, when you create an Ingress object, the GKE ingress controller creates a Google Cloud HTTP(S) load balancer and configures it according to the information in the Ingress and its associated Services.2
I'm developing an app using GCP managed Cloud Run and MongoDB Atlas. If I allow connection from anywhere for IP Whitelist of Atlas, Cloud Run perfectly works well with MongoDB Atlas. However, I want to restrict connection only for necessary IPs but I cloud't find outbound IPs of Cloud Run. Any way to know the outbound IPs?
Update (October 2020): Cloud Run has now launched VPC egress feature that lets you configure a static IP for outbound requests through Cloud NAT. You can follow this step by step guide in the documentation to configure a static IP to whitelist at MongoDB Atlas.
Until Cloud Run starts supporting Cloud NAT or Serverless VPC Access, unfortunately this is not supported.
As #Steren has mentioned, you can create a SOCKS proxy by running a ssh client that routes the traffic through a GCE VM instance that has a static external IP address.
I have blogged about it here: https://ahmet.im/blog/cloud-run-static-ip/, and you can find step-by-step instructions with a working example at: https://github.com/ahmetb/cloud-run-static-outbound-ip
Cloud Run (like all scalable serverless products) does not give you dedicated IP addresses that are known to be the origination of outgoing traffic. See also: Possible to get static IP address for Google Cloud Functions?
Cloud Run services do no get static IPs.
A solution is to send your outbound requests through a proxy that has a static IP.
For example in Python:
import requests
import sys
from flask import Flask
import os
app = Flask(__name__)
#app.route("/")
def hello():
proxy = os.environ.get('PROXY')
proxyDict = {
"http": proxy,
"https": proxy
}
r = requests.get('http://ifconfig.me/ip', proxies=proxyDict)
return 'You connected from IP address: ' + r.text
With the PROXY environemnt variable containing the IP or URL of your proxy (see here to set an environment variable )
For this proxy, you can either:
create it yourself, for example using a Compute Engine VM with a static public IP address running squid, this likely fits in the Compute Engine free tier.
use a service that offers a proxy with static IP, for example https://www.quotaguard.com/static-ip/ that starts at $19/m
I personally used this second solution. The service gives me a URL that includes a username and password, that I then use as a proxy using the code above.
This feature is now released in beta by the Cloud Run team:
https://cloud.google.com/run/docs/configuring/static-outbound-ip
I'm developing an application with MVC that uses a remote database (RDS amazon) to populate the data of the application. Running the application locally everything works fine. The problem occurrs when I deploy the application to an EC2 instance, my online application can't acess the same RDS database. What is the correct procedure to enable the EC2 instance to acess the RDS database ? My security group has at inbound and outbound permissions for all trafic and anywhere enabled.
How do I resolve problems connecting to my Amazon RDS database instance?
Issue
I am unable to connect to my Amazon RDS database instance.
Your Problem:
When attempting to connect from an EC2 instance that is not in a VPC,
the DB instance's security group is not configured to allow access by
the EC2 instance.
Solution:
If attempts to connect from an EC2 classic instance fail, grant user access from the DB instance security group. For more information, check through the following:
If you want to access your DB instance from an Amazon EC2 instance, you must first determine if your EC2 instance and DB instance are in a VPC. If you are using a default VPC, you can assign the same EC2 or VPC security group that you used for your EC2 instance when you create or modify the DB instance that the EC2 instance will access.
If your DB instance and EC2 instance are not in a VPC, you must configure the DB instance's security group with an ingress rule that allows traffic from the Amazon EC2 instance. You would do this by adding the Amazon EC2 security group for the EC2 instance to the DB security group for the DB instance. In this example, you add an ingress rule to a DB security group for an Amazon EC2 security group.
Important
Adding an ingress rule to a DB security group for an Amazon EC2
security group only grants access to your DB instances from Amazon EC2
instances associated with that Amazon EC2 security group.
You can't authorize an Amazon EC2 security group that is in a
different AWS region than your DB instance. You can authorize an IP
range, or specify an Amazon EC2 security group in the same region that
refers to IP address in another region. If you specify an IP range, we
recommend that you use the private IP address of your Amazon EC2
instance, which provides a more direct network route from your Amazon
EC2 instance to your Amazon RDS DB instance, and does not incur
network charges for data sent outside of the Amazon network.
AWS Management Console
To add an EC2 security group to a DB security group
Sign in to the AWS Management Console and open the Amazon RDS console at https://console.aws.amazon.com/rds/.
Select Security Groups from the navigation pane on the left side of the console window.
Select the details icon for the DB security group you want to grant access.
In the details page for your security group, select, select EC2 Security Group from the Connection Type drop-down list, and then select the Amazon EC2 security group you want to use. Then click Authorize.
The status of the ingress rule will be authorizing until the new ingress rule has been applied to all DB instances that are associated with the DB security group that you modified. After the ingress rule has been successfully applied, the status will change to authorized.
CLI
To grant access to an Amazon EC2 security group, use the AWS CLI command authorize-db-security-group-ingress.
Example
For Linux, OS X, or Unix:
aws rds authorize-db-security-group-ingress \
--db-security-group-name default \
--ec2-security-group-name myec2group \
--ec2-security-group-owner-id 987654321021
For Windows:
aws rds authorize-db-security-group-ingress ^
--db-security-group-name default ^
--ec2-security-group-name myec2group ^
--ec2-security-group-owner-id 987654321021
The command should produce output similar to the following:
SECGROUP Name Description
SECGROUP default default
EC2-SECGROUP myec2group 987654321021 authorizing
API
To authorize network access to an Amazon EC2 security group, call that Amazon RDS API function, http://docs.aws.amazon.com//AmazonRDS/latest/APIReference/API_AuthorizeDBSecurityGroupIngress.htmlAuthorizeDBSecurityGroupIngress with the following parameters:
EC2SecurityGroupName = myec2group
EC2SecurityGroupOwnerId = 987654321021
Example
https://rds.amazonaws.com/
?Action=AuthorizeDBSecurityGroupIngress
&EC2SecurityGroupOwnerId=987654321021
&EC2SecurityGroupName=myec2group
&Version=2009-10-16
&SignatureVersion=2
&SignatureMethod=HmacSHA256
&Timestamp=2009-10-22T17%3A10%3A50.274Z
&AWSAccessKeyId=<AWS Access Key ID>
&Signature=<Signature>
Resource Link:
How do I resolve problems connecting to my Amazon RDS database
instance?
Authorizing Network Access to a DB Instance from an Amazon EC2
Instance
Please check if the following are done.
Create a VPC security group (for example, "sg-appsrv1") and define
inbound rules that use as source the IP addresses of the client
application. This security group allows your client application to
connect to EC2 instances in a VPC that uses this security group.
Create an EC2 instance for the application and add the EC2 instance
to the VPC security group ("sg-appsrv1") you created in the previous
step. The EC2 instance in the VPC shares the VPC security group with
the DB instance.
Create a second VPC security group (for example, "sg-dbsrv1") and
create a new rule by specifying the VPC security group you created
in step 1 ("sg-appsrv1") as the source.
Create a new DB instance and add the DB instance to the VPC security
group ("sg-dbsrv1") you created in the previous step. When you
create the instance, use the same port number as the one specified
for the VPC security group ("sg-dbsrv1") rule you created in step 3.
Reference : http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html#Overview.RDSSecurityGroups.Scenarios
By default RDS does not allow any connection that is not specified within the Security Group (SG). You can allow based on CIDR addressing or by Amazon account number which would allow any EC2 under that account to access it.
but also check:
Do the associated Subnets seem properly configured?
Are the Subnets part of a Routing Group that seems properly configured (Internet Gateway specified, etc?)
Does the RDS say it's Publicly Accessible?
And of course check the RDS Security Group and EC2 Security Group
Don't forget your actual source IP may be an internal IP (if accessing internally via a VPC) or an external IP (which may be a router's IP, or an EC2 instance's Instance IP which is distinct from its Load Balancer / Elastic IP) -- to troubleshoot, you may try to allow access to all IPs and ports.
(The routing group was my problem; in creating a new subnet, I neglected to add it to a routing group with a gateway.)