While having a bastion host is a valid approach, cloud technologies have evolved, and so have the requirements for cloud networking. You either need to integrate it with central identity management or automate the management of authorized SSH keys by some other means.
You also need to control who can access which machines over those bastions and log commands executed on the machines during SSH (Secure Shell) sessions for simple audit and debugging purposes. Besides that, you usually want to have more than one bastion host, each with a different network and user access.īut bastion host management is only part of the problem. And if it’s compromised, then you’re in real trouble. If your bastion host is unavailable, then you cannot access your machines easily. It’s not something you’re supposed to do too often because most of the system configuration and maintenance must happen automatically. Typically, you’d have a bastion host to connect to your servers to do some manual operations tasks.
For years, users relied on firewalls and bastion hosts to securely access cloud assets, but these options had security and management overhead tradeoffs.
Many things have changed since then and more specifically VPCs have become the default and recommended way to use cloud resources, all using private IPs. The AWS public cloud began with Amazon EC2-Classic and networking was much simpler back then, since you could only launch an Amazon EC2 instance with a public IP. It must also be supported in a secure, auditable manner, often programmatic or via scripting, and with strong access controls. Interactive shell access to cloud or data center environments is a must in many corporate businesses.
0 kommentar(er)
