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.
If you do not see your scope here. Test EZSSH Azure Access
Policy owners are the people that can make changes to EZSSH policies.
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.
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”
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.
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.
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.
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.
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.
Enter a name to help you identify the access policy for example “admin access to prod”
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).
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
Once you have entered all the information needed for the Azure policy, click the “Create Policy” button.
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