ndomer

Hello! I am the author of this post if anyone has any questions :)

The library discussed is available on Github here: https://github.com/transcend-io/secret-value and is on npm to download via `yarn add @transcend-io/secret-value`

One big thing not mentioned here: the massive collection of managed services AWS gives you at no cost.

The biggest example is probably IAM, which makes it easy to control which servers can take what actions on which other services. And can also be integrated directly into external tools like Vault.

Want to use service discovery? No need to set up Consul/Istio/etc., just use the managed service. Same with load balancers, and VPCs, and SSM, and route53, etc.

Sure, in 2020 none of those services are that hard to replicate pieces of, and open source tools abound. But setting up those tools all takes time.

Only other nit is that the article makes it sound like Terraform and IaC is meant to abstract away AWS vs GCP such that one terraform module _could_ be deployed to either just by changing some string value from "AWS" to "GCP". I don't believe any serious (and good) efforts are being made in that space, and you won't find any popular modules like that on https://registry.terraform.io/.

Apologies for the confusion! I picked BeyondCorp as there seems to be a number of references to it as a more general-cloud term than anything Google Cloud specific.

As some examples, https://www.beyondcorp.com/ is run by the IdP Okta, and ScaleFT (a zero trust SaaS company) references the philosophy of BeyondCorp as being used outside of Google: https://www.scaleft.com/blog/beyondcorp-outside-of-google/

(Author here)

At Transcend, we use a bastion host (like others have mentioned). The key difference that we do that I don't think has been covered is that our bastion only makes outgoing connections, and has no open ports to the world.

Using the AWS SSM managed service, we can create bastions that have no ingress at all.

I talk through some different approaches in a codelab over here: https://codelabs.transcend.io/codelabs/aws-ssh-ssm-rds/index...

(Author here)

I think the second most secure way to handle service authentication is to protect your ports with strong auth, like this article talks about.

But the most secure way to handle this is to just eliminate the open port entirely.

Here's another post of mine where I talk about making a bastion host with no open ports and no ingress on its security group: https://codelabs.transcend.io/codelabs/aws-ssh-ssm-rds/index...

This is a great question! I hoped this would get brought up, as it is very important. I decided against covering in this blog as I felt it was already fairly long, but the tldr is that I see two incremental ways with this setup to add authorization:

1. Cognito has something called "Adaptive Authentication" that will compute risk scores for each login based on IP, device info, etc. You can customize in the AWS console how risk-tolerant you want to be.

2. You can go the fully-managed approach, which is what we are implementing at Transcend now. The idea is that you'd use an MDM like Fleetsmith to install a TLS cert onto each managed device, and then validate that cert on each request in the auth portal. There are lots of cool ways (we use the Vanta agent) to verify that a users' device is "good" to authenticate with.

I'd like to write more about option 2, but I try to keep this blog posts as technology agnostic as I can, and my experience is fairly limited right now to Vanta + Fleetsmith

(Author of the blog here)

This is a great question! I hoped this would get brought up, as it is very important. I decided against covering in this blog as I felt it was already fairly long, but the tldr is that I see two incremental ways with this setup to add authorization:

1. Cognito has something called "Adaptive Authentication" that will compute risk scores for each login based on IP, device info, etc. You can customize in the AWS console how risk-tolerant you want to be.

2. You can go the fully-managed approach, which is what we are implementing at Transcend now. The idea is that you'd use an MDM like Fleetsmith to install a TLS cert onto each managed device, and then validate that cert on each request in the auth portal. There are lots of cool ways (we use the Vanta agent) to verify that a users' device is "good" to authenticate with.

I'd like to write more about option 2, but I try to keep this blog posts as technology agnostic as I can, and my experience is fairly limited right now to Vanta + Fleetsmith

For sure, VPNs will always be used. I think it'll take a BeyondCorp SaaS company to really take off (or have it become a more "Managed"auth method from the big cloud providers).

At Transcend we are able to do it because we had an early focus on protecting our internal apps, but obviously it's a lot harder to migrate hundreds of services than to start out with a newer approach.

I loved not having to use a VPN back when I worked at Google though, and am glad to see that the open source world is starting to offer some tools to play around with.

Hello everyone! At Transcend, we've used BeyondCorp for all of our internal sites, as well as for our communication between services.

Please let us know if you have any questions about getting started :)

This blog post aims to show that not only are making Lambda@Edge functions in Terraform possible, but that it can actually be a pleasant experience.

Hello! I authored this post, and would love to get some community feedback.

I've really enjoyed using both Terraform and Terragrunt, and think you and your company would as well.

Please let me know if there are any questions I can answer