But it seems no one like Azure these days, but they have some nifty features.
"Tunnel created using SSM only allows single connection to destination port" - https://forums.aws.amazon.com/thread.jspa?threadID=314882&ts...
This has been sitting open in the support forums unanswered for over two months :/
1) Is logging for access from CLI finally supported?
2) Can I setup which shell is used?
3) Are logs readable when I switch to something else than sh?
4) Is U2F supported (awscli question)
Once all of these are fixed, then it can be possible to claim that SSM solves these issues. Otherwise it’s nothing more than for adhoc usage.
we have some regulatory requirements that require us to use hardware tokens for 2FA access to servers.
2. what about SSH tunnels ?
If you're doing a federated login with Okta or another provider, you need to set up the hardware MFA there.
There is SSH tunneling support as well, will add an update on that soon.
We currently connect via SSH to a bastionhost, then tunnel from there to various systems, which allows connecting to SSH (linux instances), RDP (Windows), or basically any other network services like Redis or a database. I ended up writing some scripts to automate all this, so as long as you have the right certificates and IAM permissions, you can connect with a single command -- for Windows instances, it even retrieves the randomized password from the EC2 API. The end result is for any EC2 instances you're instantly popped into a shell/RDP session without having to enter credentials.
I'd love to replace this with something better (eg Session Manager), but I've not seen how to do this for RDP, and haven't had the time to go experimenting on my own to see if it's even possible. If I can't 100% replace the bastionhosts, having two entirely different connection methods doesn't solve anything (and in fact makes it worse, because it's harder to use).
Which documentation do you mean? The article mentions the policy AmazonSSMManagedInstanceCore, which is the same as what's mentioned in the SSM setup guide:
Though I always suggest to read what managed profiles are doing. Many of them are very permissive
>"No more bastion hosts required! Session Manager uses AWS APIs to communicate with your instances, so you can remove the administrative burden of maintaining bastion hosts."
Does this presume the EC2 instances have a public IP or is there a way this would also work with EC2 instances on private subnets?
Currently I have an EKS cluster accessible only on private subnets. It would be wonderful to to be able to access this without OpenVPN in the mix.
Connectivity from a private subnet to the AWS API could be (a) NAT gateway (b) HTTP proxy (c) PrivateLink VPC endpoint.
Would be interesting to lock down the session manager agent (if possible) so that the only way to privileged access is through sudo-like priv esc that uses 2fa.
For federation you need to rely on the config in whatever your identity provider is, like Okta.
So if you already have access control setup on your host, then SSM doesn't do anything to undermine it. If you don't have it, you'll still need to add it.