How to Create First Azure Policy
Prerequisites
Overview
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.
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”
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.
For Auto Adding to work, EZSSH Needs contributor access to your subscription.
Note
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.
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.
Tip
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