Probably because the blog post is an advertisement for their product, which already allows you to implement bastion hosts as you describe.
From the bottom:
> Databases do not need to be exposed on the public Internet and can safely operate in air-gapped environments using Teleport’s built-in reverse tunnel subsystem.
Not sure what there reverse tunnel product is, but a bastion host is super easy to implement, just spin up an ec2 and walla.
Curious as to what value they are providing
https://www.collinsdictionary.com/dictionary/french-english/...
Haven't used them myself but I wouldn't be against trying it if in the market for something like that.
The same is true for server applications that have weird 3rd party dependencies that may go down when you least suspect it.
Bastion<->app host<->DB
Bastion can talk to the net.
App host can talk outbound but inbound only accepts bastion and DB.
DB can only talk with app host.
Obviously, you harden everything appropriately... But with this arrangement, it's very difficult to penetrate this sort of network. Think of it as a network that as a whole is default-deny.
Edit: To add some details - using ProxyJump you don’t have to expose anything to the jump host and instead just proxy through it.
In cloud environments, it's straightforward to update network firewall rules as IP addresses change. Residential and office IP addresses don't change much so it's not much of a hassle in my experience. That said, it can get annoying if you find your self working on a network that rotates your IP address frequently (e.g., a hotspot).
You could then use a bastion to access servers in the private subnet, or use something like AWS Session Manager which provides command line access via web browser in lieu of a bastion.
Adding more mechanisms on top is pointless when the effort could be invested in, for example, automated auditing of SGs, which is vastly more potent from a hardening perspective than adding additional layers of technical redundancy that are still exposed to the same flawed human processes.
When you reach a team of 10-20 folk on a project, stuff tends to get confusing and/or lazy with elaborate configurations. Security design therefore is about more about managing that outcome through simplicity and process hardening than.. well.. I don't even know what threats a separate VPC protects against
From the perspective of maintaining security in the least confusing way possible in a team setting, I could see a scenario where you have a VPC that only has private subnets, and no public subnets at all.
You could call it “Database VPC” and assuming your team doesn’t reconfigure the VPC to add public subnets, you can be comfortable with your team adding more EC2 servers / databases / whatever in that VPC since they would all be in private subnets inaccessible by the public internet.
And then you could have a 2nd VPC with private/public subnets that are less locked down than the database VPC, which might contain your load balancers, application servers, etc.
I suppose the benefit would be the logical separation of databases into a VPC without any public subnets. And the only way to gain access to subnets in that VPC would be through VPC peering.
(The above assumes you’re using AWS). Although after typing all that, I still think you can accomplish a comparably secure (on a network level) architecture using security groups, or even separate subnets, without separate VPCs.
In general I try to avoid multiple VPCs because VPC peering in AWS can get tricky (or impossible if both VPCs have overlapping CIDR blocks).
I also limit access to just one IP, which is a VPN server hosted on a different cloud provider.
You can run a bulletproof VPN server easily using something like algo (https://github.com/trailofbits/algo)
Email is one such way.
I'm sorry but could you clarify? You mean that you monitor and/or collect data from hosts inside of a network via email somehow?
Your inbox needs to be an automatable inbox, say controlled by bleeder or another flowengine. From there you can build a full messaging dashboard and have it done in something that could pass a very stringent audit.
I then use a bastion host when I need to access ssh on the instance. The bastion host remains off and inaccessible except for when I need to perform maintenance.
The advantages of this is that there is no "always-open" access to the instance.
Not sure why the author does not advocate this.