How-To: Create Your First Azure Policy

1. 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

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”

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.

Endpoint Management

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.

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.

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).

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.

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. 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. 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. 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. 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. 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. 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. 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.

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.

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.

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