Week 26, 2019 - AWS App Mesh and Cloud Map; IAM Access Advisor; Azure Bastion

By Arjen Schwarz (4 minutes read)

AWS integrates App Mesh and Cloud Map and releases a way to review your Service Control Policies for an account. In the meantime Azure released a managed Bastion service.

AWS App Mesh And Cloud Map

As I’ve written about AWS App Mesh before, I was happy to hear about the new integration with Cloud Map. In case you’re not very familiar with these two services, App Mesh is a managed service mesh while Cloud Map is purely for service discovery.

This integration means that you can now use a Cloud Map endpoint as the backend for your VirtualNode in App Mesh. Which is great if you’re using a service as tightly integrated with Cloud Map as ECS¹, but doesn’t help much if you run your stack on EKS as Cloud Map only maps the external endpoints for that. There isn’t anything to prevent you from mixing and matching things in a single Mesh, but you will get the most benefit out of this integration if you use App Mesh with an ECS stack.

To be clear, that doesn’t make it any less useful. Especially as for many use cases EKS (and Kubernetes in general) is likely overkill and you’d be far better served using ECS/Fargate². Writing this, it also makes me wonder if you can use it, now or in the future, to connect to other non-container services in your App Mesh.

IAM Access Advisor

The new IAM Access Advisor for Organizations sounds like a great new feature. It allows you to review exactly what permissions have been used in an account so you can then limit the capabilities to these accounts even more. There is a caveat though, and that is that you need to have a Service Control Policy applied already to the account before it can be of use.

If you don’t have that, you won’t be able to see any information yet and can’t get an overview of what you should limit it to. Of course, you should apply SCPs anyway³ and there are many limitations you can safely apply to your accounts⁴. Once you’ve done that you can then review what is actually used in your accounts and tighten those controls even more.

Azure Bastion

While only in preview, Azure released a managed bastion service. Now, I’ve mentioned often enough that I don’t believe anyone should run bastion hosts. I still stand by that, but Microsoft did a pretty good job here providing something that is transparent for the users.

Basically, they have expanded on the ability to log into a shell directly from the Portal⁵, as by running the managed bastion service⁶ you can not only log into a shell but even use it for RDP access directly from the browser. This looks quite impressive when you watch the video. I do wonder if you can control access for using the bastion server, so you would have a second layer of authentication on top of the usual Windows username and password⁷.

That concern to the side, it is a better solution than running your own bastion hosts if you absolutely need to be able to access your servers. And from a technical perspective it’s great. I would just prefer it if this wasn’t necessary in the first place.

Ambassador Corner

Including Fargate. ↩︎
Or even go straight to a serverless solution if that’s possible. ↩︎
And yes, obviously I ran into this on my personal accounts so this is a “do as I say” kind of thing. ↩︎
Blocking out regions you don’t actively use is a big one. As are services you’re unlikely to ever use. Remember, if in the future you suddenly do need access to Sumerian in the account running your website you can update the SCP. ↩︎
I’d say it’s similar to the AWS Systems Manager Session Manager, but Azure had the functionality first so that’s not really fair. Although I prefer the AWS implementation. ↩︎
You still need to open ports etc. in your subnets. ↩︎
I’m sorry, but I always feel that just a username and password isn’t enough to protect my servers. That is too easily copied just by looking over someone’s shoulder. ↩︎

Connecting the dots