As part of your Cloudlets configuration, the person with administrative-level access to your organization's Akamai account needs to set up permissions for your Cloudlets.

📘
Edge Redirector has special roles you can use when setting up your users.

How permissions work with Cloudlets

When working with Cloudlets, be aware that your level of access depends on the groups and roles associated with your Control Center username. If your username is part of the group that contains your Cloudlets policies, you can't set up rules in Cloudlets Policy Manager.

You can only associate a Cloudlet policy with a property that is in a compatible group. A compatible group can be the same group, or be an ancestor of the policy's group.

Cloudlets permission levels

Each Cloudlet comes with a set of predefined permissions. In order to work with a Cloudlet, a user will need a role that contains at least one permission setting for that Cloudlet. The actions the user can perform for that Cloudlet will depend on the permission level set in the role.

By default, all Cloudlets permissions include the ability to view both the Cloudlets Policy Manager and Cloudlets reports.

The following table lists the standard permission levels available for Cloudlets, where CloudletName is the name of the Cloudlet, like Application Load Balancer.

Permission Level	Description
CloudletName Viewer	Enables users to see and view the contents of policies and policy versions.
CloudletName Editor	Enables users to: see and view the contents of policies and policy versions. create, delete, and update policies and policy versions.
CloudletName Admin	Enables users to: see and view the contents of policies and policy versions. create, delete, and update policies and policy versions. activate policy versions.

Determine the access model components for your Cloudlets

This task is very specific to your organization and to the set of Cloudlets you use. Depending on your organization's needs, you may need to add new groups and roles for your Cloudlets, or just use your existing access model structure.

When considering how to structure your access model, ask yourself questions like these:

Question	Example Answers
Groups
Will you need multiple groups to support your Cloudlets?	We're using this Cloudlet with two separate properties. I want two separate groups for Cloudlets because we don't want users that work on the one property to access Cloudlet policies on the other property.
Can you use any of your existing groups for your Cloudlets implementation?	I'm going to create a subgroup for my Cloudlet. Why? I already have a group for the department that will use this Cloudlet most. In the subgroup, I'll limit access to only the people working directly with the Cloudlet.
Roles
How are you breaking down the Cloudlets-related tasks across your organization?	We want to use the same process we use for our other site changes: one person makes the changes, while another deploys the changes. To keep things consistent, I want to have distinct editor and administrative roles for our Cloudlets.
Can you use any of your existing roles for your Cloudlets implementation?	The team already has view, edit, and administrative roles set up, so I'll just add the appropriate Cloudlet permissions to those roles.
If you have multiple Cloudlets, what levels of access do you want to provide for your users?	All Cloudlets users should be able to view policies for all Cloudlets. Only users working directly with a Cloudlet should have editorial and administrative permissions. Given this, I'll set up multiple roles specifically for our Cloudlets.