Bastions on demand in an AWS VPC
theconsultingcto.com
theconsultingcto.com
[1] https://docs.aws.amazon.com/systems-manager/latest/userguide...
I've tried using it for development, and it was a terrible experience. The connections would hang all the time for no reason. I ended up starting an SSH session (via SSM) and done the port forwarding via that...
[0] https://docs.aws.amazon.com/systems-manager/latest/userguide...
Huge shameless plug for the coolness that is Session Manager, I can only think of a few scenarios where you wouldn't just prefer it over the alternatives. If you haven't played with it (or other SSM stuff), you totally should! It's cool and useful and easy and more or less free.
If you're interested in more feedback, I'd be happy to share. As with many things AWS, there were some undocumented rougher edges that took some trial and error to figure. Although the end result was well worth it. Totally understand if you're not on HN to do that sort of thing, though.
e: or put an email in your profile and I'll even reach out!
Also can u restrict access to ssh through ssm to certain ips?
Maybe I might have missed these, so any help would be appreciated.
Technically there is, you can use federated login. Might not be very convenient, depending on your identity provider.
A solution I use, while not technically "not using access kys" is storing them in the system credential store with aws-vault [0]. Works on Windows, Linux and Mac. And you can combine this with multi factor auth.
> Also can u restrict access to ssh through ssm to certain ips?
Yes, with an IAM policy. The policy below requires connecting with an MFA and from a specific IP range. It only allows connecting to a specific instance.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": [
"arn:aws:ec2:eu-west-3:123123123123:instance/i-123123123123",
"arn:aws:ssm:eu-west-3::document/AWS-StartPortForwardingSession",
"arn:aws:ssm:eu-west-3::document/AWS-StartSSHSession"
],
"Condition": {
"IpAddress": {
"aws:SourceIp": "1.2.3.4/32"
},
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
[0] AWS Vault: https://github.com/99designs/aws-vault/If you can make a good case for it, open a ticket or make a stink on the forums and there's a chance an engineer can be tasked to add it to their list of Officially Supported Platforms. This is how eg raspbian got added, though I don't know if the program is still running for adding platforms as it's been a few years.
Seems to me that the bastion approach is a bit weird at this point; no node should be directly attached to the public internet (unless you enjoy babysitting one). You usually have an LB in front of it, then perhaps a CDN+WAF (like CloudFlare) in front of that. The same can be done for SSH and even RDP.
The concept that your bastion is 'more secure' than your other systems needs to go away, make all of the systems that secure to begin with if you want to allow human access and shells.
Some people are using wireguard containers on Fargate to do the same thing.
OpenVPN is a hot mess, but is currently the most supported mechanism across platforms.
Background: I want to give my (100% global remote) development team network access to our AWS dev environment Aurora Postgresql, EFS / NFS, redis, microservices, etc. We already have a local env with docker-compose but need to debug and test in the shared cloud dev environment.
Most of our setups use OpenVPN via OpnSense on AWS, second most popular option is OpenVPN-AS with a paid license, third is AWS OpenVPN, because of the price tag.
A few test setups rely on a small EC2 instance per group (t3.small for example) with a single container and it's a bit quirky to automate, especially on large user groups.
This is our main issue with WG in production so far: while the technology seems totally fine, it's not at a point where you can smoothly roll out a 'service' and get going, there are too many hoops to jump through and too many duct-tape constructions to make it integrate. (somewhat ironic, considering OpenVPN)
In the simplest form, I'd go with AWS CloudFormation of an EC2 instance. Remove the additional step of an ECS cluster if you don't already have one. An EC2 instance can access cluster VMs, or other VPC objects just as easily. Can it's wrap this in AWS SAM or CloudFormation + a controller like GitLab or Jenkins...
The benefit here is that when you're done, you have an AWS CloudFormation stack to kill... No need for anyone to have teraform installed to find and remove all associated resources.
Of course, this is all if you can't use Systems manager or the CLI to achieve your goals
Because it's easy to throw containers at the problem. Coupled with savings plans this can be pretty cheap.
> why terraform
Because it's easier for most than CloudFormation, and has all the benefits of decomposable stacks just like CF.
I think it’s better with VPN plus SSM.