Introducing: native integration with AWS tags for SSH access management


A recent discussion with a customer running its environment on AWS went like this: “I have a very dynamic environment where I can dynamically create and teardown hundreds of servers in minutes and in certain cases I need SSH access to them. How can I do that with Luminate while maintaining the Zero Trust approach of not putting users on the network?”

My immediate answer was – automate access via API. But then, in thinking about this scenario and discussing it with other customers, we realized that this is a pain-point shared across multiple customers running on AWS.


Seems like a good challenge to solve!

So, we gathered a few smart people into a room… and…. [drum roll here]:

As of last week, we are able to natively support SSH authorization policy based on AWS Tags!

The solution ended up being very simple and intuitive –

  1. Choose the AWS account (or accounts) to which you want to provide access.
  2. Define an SSH authorization policy - the IdP users that are allowed to SSH using certain local SSH accounts.
  3. Define the VPCs and AWS Tags which are shared across all the EC2 instances to which the users are allowed SSH access.
  4. Et voilà! Tag based Zero Trust SSH access!


Who should use it and how?

Turned out that customers have been waiting for such a feature and welcomed it with open arms, quickly implementing it on several scenarios:

  1. Allow DevOps access to production environments. Apparently, there is a key value tag for this – the key name is ‘environment’ and values are ‘production’ or ‘test’.
  2. Allow the Dev team access to their respective applications/components, using the ‘application’ key which contains the value of specific applications spanning multiple EC2 instances that can dynamically change.
  3. Support access to environments that are managed using Spot instances and that are constantly being brought up and down. In this case, one of the few things shared by these environments are the AWS Tags which are assigned during the instance’s startup.


What’s in it for you, you ask?

It’s all about efficiency.

AWS Tags enable you to categorize your AWS resources in different ways. This is very useful when you have many resources of the same type and you want to treat them all in the same manner, no matter which resource you’re dealing with and where they are deployed. Then you can quickly identify a specific resource based on the tags you've assigned to it. You can extend your AWS Identity and Access Management (IAM), to control which users in your AWS account have permission to create, edit, or delete tags.

The integration of Luminate with the AWS tags taps into this efficiency wave. It adds another level of productivity that results in an easy, quick and mostly dynamic access setup and management process.

Why replace your VPN? Read the whitepaper

How to set it up?

Setup it up in three steps:

  1. Integrate your AWS VPC with your Luminate. You would need to create an IAM Role for Luminate’s account and provide it with read-only permissions: 

Inside image 1 PNG-1

  1. Create a new SSH Gateway application in which you’ll define the VPC and tags: 

Inside image 2 PNG

  1. SSH Away to any IP address or hostname in the VPC – simply enter the hostname or IP address of the target EC2 instance in the Luminate AppPortal and execute the command generated: 

Inside image 3 PNG

If you use the AWS tags or you’re thinking of going this way, if your environment is dynamic and needs to scale up and down quickly, you should look into this integration and take it for a test drive!


P.S - You could also combine this with your multi-factor authentication integration to require MFA when SSHing into specific ‘Tags’, which is a super cool extension for this IMHO, but that’s for a different post.

Michael Dubinsky, VP Product

Written by Michael Dubinsky, VP Product

Michael Dubinsky is an experienced entrepreneur and product executive leading Luminate’s product strategy and execution. Prior to joining Luminate, Michael was leading the product team for Aorato (acquired by Microsoft) and successfully launched the product as Microsoft Advanced Threat Analytics, achieving wide enterprise customer adoption. Previously Michael held multiple customer-facing roles at Microsoft and HP.