Permissions

The permissions we have in the environment we try to scope and limit as much as we can but enough to still allow for us to effectively manage the environment. We also want to ensure that users have as many permissions as they need to do their jobs effectively, but are also limited according to the principle of least privilege.

With all this in mind, to allow us to deliver the best possible product, here are the permissions we require in order to effectively deliver the best possible product and the purpose behind requesting these permissions.

We also advise that we place all write permissions of our engineers behind PIM (Privileged Identity Manager). We have some extra elavated permissions below based around this, but we also need Entra ID P2 licences assigned to the Entra ID Group of our engineers. These licences cost 99kr per user and will need to be assigned by the customer before we will enable PIM as Azure will not block the usage of PIM even if the users do not have the requisite licence and can claim all costs plus potentially penalties.

Entra ID

1. Directory Reader/Directory.Read.All

This is used so that we can use infrastructure as code to do lookups on the Azure Entra Groups from the display name of the group as an example. We would use this when granting access to Groups on resources at a management group level or sometimes on a lower resource level if required. Being able to use the Display Name of the Entra ID allows us to visually have more context on the group and ensure that we can communicate as efficiently as possible.

1. Azure RBAC Access Control Administrator/RoleManagement.ReadWrite.Directory

This is required so that we can grant accesses to Entra ID groups or when dealing with services running in the environment, granting access to managed identities.

1. User Administrator/User.ReadWrite.All

Required in order to be able to manage the Playground Tech users in the customers tenant. Users are not added/removed very often but it allows Playground Tech to give the best experience as we follow our onboarding/offboarding processes for users.

1. Groups Administrator/Group.ReadWrite.All

Required to manage the Playground Tech groups that the Playground Tech users will be a part of.

1. Groups Administrator or User Administrator/GroupMember.ReadWrite.All

This permission is used to manage the users of the Playground Tech groups. Users are not added/removed very often but it allows Playground Tech to give the best experience as we follow our onboarding/offboarding processes for users.

1. Guest Inviter or User Administrator/User.Invite.All

This is used to invite members of the Product and Operations team from Playground Tech to have a user inside the customers tenant. Users are not invited very often but it allows Playground Tech to follow it's automated onboarding/offboarding processes.

1. Privileged Role Administrator/PrivilegedAssignmentSchedule.ReadWrite.AzureADGroup + PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup

The requirement of this role is dependant on if Playground will be required to use PIM to gain write privileges for it's engineers. This is so that we can add our team members and manage their ability to PIM.

1. Cloud Application Administrator/Application.ReadWrite.OwnedBy or Application.ReadWrite.All

Tenant Root Group

1. Reader

So we can use infrastructure as code to integrate with the existing environment. An example of this is using a data lookup on an existing virtual network so that we can add the virtual network cidr range to the firewall ensuring that we have the correct cidr and that we can communicate with each other using names rather than ips.

1. Container Registry Configuration Reader and Data Access Configuration Reader

This allows fetching of the username and password to pull from a private Azure Container Registry. This is not necessarily needed to pull docker images but if ACR is used as an OCI store for helm charts, then with ArgoCD 2.x the username/password from the ACR needs to be passed. This role ensures they can be fetched programatically.

1. DNS Zone Contributor

We use this to allow us to add DNS Records for when we are not using our External DNS service. An example of this is creating a DNS record for an Azure Application Gateway with a virtual machine scale set behind it. This is not necessary if the DNS zones reside in a subscription below the Playground Tech Root management group. See [Management Groups][Management Groups] for details on this structure.

1. Private DNS Zone Contributor

We use Private DNS Zones in azure to allow for private access to Azure native resources such as Azure Key Vault or Azure Blob Storage. A full list of potential Azure services that can have their access enabled over azure private

link with private dns can be found here. This is not necessary if the DNS zones reside in a subscription below the Playground Tech Root management group. See Management Groups for details on this structure.

Playground Tech Root Management Group

As laid out in Management Groups, we create a "Playground Tech Root" management group to contain the subscriptions where the managed services will reside.

1. Owner

This is so that we can create resources and manage the subscriptions that are part of the managed services offering.

1. Key Vault Administrator

For all key vaults inside the subscriptions that reside in the Playground Tech Root management group. For customers that do not want Playground Tech to have access to their Key Vaults, the reccommended solution can be found in the Key Vaults documentation.

1. Azure Kubernetes Service Cluster Administrator

For all AKS (Azure Kubernetes Service) clusters residing in subscriptions that are below the Playground Tech Root management group. This is so that we can access, manage and help debug with the customer when required.