How-To: Create Your First Azure Policy

Azure Policies are the best option for easily and seamlessly connecting to Azure SSH endpoints using AAD Identities. The policy will have a scope (Subscription or Resource Group) and will manage access to the resources inside the scope.

Prerequisites

Overview

Video Version

Getting Started

Go to https://portal.ezssh.io/
Navigate to Azure Policies
Click on the “Create New Policy”
Enter Policy Name: This name is just to make it easier for users to know what this policy gives them access to.
Enter Notification Email: Usually a team DL that would get notifications for changes to the policy.
Select the Scope Type
Select the Policy Scope from the dropdown.
Note

If you do not see your scope here. Test EZSSH Azure Access

This will expand the rest of the creation page.

Adding Policy Owners

Overview

Policy owners are the people that can make changes to EZSSH policies.

Adding Owners

Note

By Default any Owner or Contributor of the Scope will be an owner of the policy. In addition, you can add other Azure roles or AAD objects to be added as owners.

Adding AAD Objects as Owners

In the AAD Owner section enter the UPN or group name of the owner you want to add to the policy. and click “Add Owner” EZSSH Agentless JIT Access Azure policy AAD Owners and Azure Roles Owners configuration section

Adding RBAC Roles as Owners

In the right hand side you can add any RBAC Roles that if a user is ACLed to that scope under that role will get owner privileges over the EZSSH policy. EZSSH Agentless JIT Access Azure policy Azure Roles Owners list with Owner and Contributor RBAC roles added

Endpoint Management

Below the Owner Section, you will see the list of your endpoints that EZSSH found in your scope. If you don’t see all the endpoints, please make sure EZSSH has at least Reader access to the endpoint and that the endpoint is in the scope selected. EZSSH Agentless JIT Access Azure policy endpoints table showing VM name and IP address

Auto Adding EZSSH to Endpoints

For Azure policies, EZSSH offers the option of automatically adding the policy’s certificate and the allowed principals to your Azure endpoints. If you want EZSSH to automatically add the EZSSH certificate to your existing Azure endpoints and to any new endpoints it detects, select the checkbox under the endpoint table. EZSSH Agentless JIT Access endpoint table with auto-add principals to subscription checkbox enabled

Note

For Auto Adding to work, EZSSH Needs contributor access to your subscription.

How EZSSH Adds Certificate to Azure VMs

EZSSH uses Azure VM extensions to send our bash script that will add the certificate to the machine. This means that EZSSH will never access your endpoints or install an agent in your endpoints, all the installation will happen through Azure and the authentication using native OpenSSH.

Creating Access Policies

Overview

Up until now we have set up: the scope of the policy, who can manage the Azure Policy, and how will the endpoints be managed. Now we have to create who will have access, for how long and with which Linux user. For this we have the access policies. One policy can have multiple access policies.

Basic Details

Access Policy Name

Enter a name to help you identify the access policy for example “admin access to prod”

Max Certificate Length

This is the Maximum amount of time that users can request their certificate for (how long the user will have access after the request is approved). The accepted values are between 1 hour and 168 hours (one week). EZSSH Agentless JIT Access Create New Access Policy form with Access Policy Name and Max Certificate Length fields

Linux Principals

This are the usernames that you will be able to login to Linux with enter all the ones your team uses and you want this policy to have.

Tip

Reminder: you can have multiple access policies to the same endpoints so if you want to break it up that only some people have access to some and others have access to others, create multiple access policies.

Enter the principal name, enter a note (for your team to know what that gives them access to), and check whether it has sudo permissions. Once you have entered all the information click the “Add Principal” button. EZSSH Agentless JIT Access Linux Principals section with root principal added showing sudo permission enabled Repeat this step for all the Linux principals you want in this access policy.

Auto Approved

Auto approved principals are principals that will be able to request access to the endpoint without needing the approval of someone else in the team. This is ideal for automation accounts, and On-Call engineers.

Adding AAD Objects as Auto Approved Requesters

To add an AAD Object as an auto approved requester, start typing the object’s name under the “Allowed AAD Objects” in the auto approved section. EZSSH Agentless JIT Access Auto Approved section with AAD Objects search dropdown showing user result Once the object appears in the drop down, click on it and click the “Add Requester” button. Repeat these steps to add all the desired Auto Approved AAD Objects.

Adding Azure RBAC Roles as Auto Approved Requesters

In Azure Policies, EZSSH Allows you to add roles to be auto approved requesters. This means that any object with that role to the endpoint will be able to be auto approved. For example, if we add the owner role, anyone that is an owner in Azure, will have auto approved access to the endpoint.

To add a role as an auto approved requester, start typing the role’s name under “Allowed RBAC Roles” in the auto approved section. EZSSH Agentless JIT Access Auto Approved Allowed RBAC Roles search dropdown showing Owner role option Once the role appears in the drop down, click on it and click the “Add Requester” button. Repeat these steps to add all the desired Auto Approved Azure roles.

Manually Approved

Manually approved principals are principals that will be able to access endpoints only after they have been approved by a member of the approvers group. If Azure roles or AAD objects are added as requesters of a manually approved policy, at least one Azure Role or AAD Object is required as an approver.

Adding AAD Objects as Approvers

To add an AAD Object as an approver, start typing the object’s name under the “Allowed AAD Objects” in the approver section under the manually approved section. EZSSH Agentless JIT Access Manually Approved AAD Approvers search showing matching group in dropdown Once the object appears in the drop down, click on it and click the “Add Approver” button. Repeat these steps to add all the desired approver AAD Objects.

Adding Azure RBAC Roles as Approvers

In Azure Policies, EZSSH Allows you to add roles to be Approvers. This means that any object with that role to the endpoint will be able to be an approve access to that endpoint. For example, if we add the owner role, anyone that is an owner in Azure, will be able to approve access to the endpoint.

To add a role as an approver, start typing the role’s name under “Allowed RBAC Roles” in the approver section under the manually approved section. EZSSH Agentless JIT Access Manually Approved Azure Approver Roles search dropdown with Owner role highlighted Once the role appears in the drop down, click on it and click the “Add Approver Role” button. Repeat these steps to add all the desired approver Azure roles.

Adding AAD Objects as Manually Approved Requesters

To add an AAD Object as a manually approved requester, start typing the object’s name under the “Allowed AAD Objects” in the requesters section under the manually approved section. EZSSH Agentless JIT Access Manually Approved Requesters with AAD Objects search showing user in dropdown Once the object appears in the drop down, click on it and click the “Add Requester” button. Repeat these steps to add all the desired Manually Approved AAD Objects.

Adding Azure RBAC Roles as Manually Approved Requesters

In Azure Policies, EZSSH Allows you to add roles to be manually approved requesters. This means that any object with that role to the endpoint will be able to get access to the endpoint once it has been approved by an approver. For example, if we add the owner role, anyone that is an owner in Azure, will be able to request access to the endpoint.

To add a role as a manually approved requester, start typing the role’s name under “Allowed RBAC Roles” in the requesters section under the manually approved section. EZSSH Agentless JIT Access Manually Approved Requesters RBAC Roles search showing Virtual Machine Contributor option Once the role appears in the drop down, click on it and click the “Add Requester” button. Repeat these steps to add all the desired Manually Approved Azure roles.

Adding the Access Policy to the Azure Policy

Once the access policy is complete, the “Add Access Policy” button will be enabled. Click the Button to add the access policy to the Azure policy.

EZSSH Agentless JIT Access access policy form showing Add Access Policy button enabled and ready to click

Adding an Additional Access Policy to the Azure Policy

If you want to add additional access policies to the Azure policy click the “Add Another Policy” button.

EZSSH Agentless JIT Access Azure policy with Add Another Policy button highlighted to add second access policy

Add all the needed information for that access policy and add it to the Azure policy.

Repeat these steps until you have added all the needed access policies.

Saving the Azure Policy

Once you have entered all the information needed for the Azure policy, click the “Create Policy” button.

EZSSH Agentless JIT Access Azure policy form with Create Policy button highlighted to save and create policy

Adding EZSSH Certificate Authority Access to Endpoint

If you enabled “Auto Adding EZSSH to Endpoints you are ready to start using ezssh.

If you opted for manually adding the EZSSH Certificate Authority to your endpoints, follow this guide to manually add EZSSH CA to your endpoint.

For future endpoints, read Adding EZSSH Using Cloud Init and our example using Pulumi