# Keys
> Keys are the atomic unit of access control
In Layer5 Cloud, permissions are represented as keys, each serving as a unique identifier for a specific permission. One or more keys can be grouped together and assigned to a [keychain](/cloud/concepts/identity-and-security/keychains/). Then this keychain can be assigned to a [role](/cloud/concepts/identity-and-security/roles/) and that role can be assigned to a user. This is the general flow of how keys are assigned to a user.
For instance, consider a system shipped default key `Create Organization`, which corresponds to the permission to create an organization in the Cloud. This implies that to create an organization, you need to have `Create Organization` key assigned to a keychain, which, in turn, is assigned to a role that's associated with your user account for a given organization.
Note
- Same key can be asssigned to multiple keychains.
- One or more keys can be assigned to a keychain.
- Each key is assigned in context of an organization.
Because every key is evaluated in the context of an organization, a user's *effective* set of keys can — and will — differ from one organization to another. The same person holds whatever capabilities their role(s) grant them **within each specific organization**, so being able to perform an action in one organization implies nothing about the same action in another. This is why an organization context is itself an authorization boundary. For how this fits with authentication and cross-organization resource sharing, see [Identity and Security → Security Boundaries](/cloud/concepts/identity-and-security/#security-boundaries).
### Keys Types
Generally, there are four types of keys:
1. **Create** - Create keys permit you to create resources. For example, `Create Organization` key allows you to create an organization.
2. **Read** - Read keys permit you to access and retrieve resources. For example, `View All Teams` key lets you see all the teams within a selected organization.
3. **Update** - Update keys permit you to update resources. For instance, `Update Organization` key allows you to update an organization details.
4. **Delete** - Delete keys permit you to delete resources. For instance, `Delete Organization` key allows you to delete an organization.
Some keys do not fit any of those four shapes, because the action they grant is not simply creating, reading, updating or deleting something. For example, the `Approve Catalog Request` key allows you to approve a catalog request to publish a cloud-native design to [Cloud Catalog](/cloud/concepts/catalog/), and the `Connect GitHub Account to Workspace` key enables you to connect your GitHub Account to your [workspace](/cloud/concepts/spaces/workspaces/) in the context of any organization.
### Keys Enforcement
The primary purpose of key enforcement is to ensure that you can only perform actions for which you have the necessary permissions within the context of your selected/available organization. This is achieved by disabling or hiding the UI elements associated with actions for which you lack the required permissions. This approach not only provides clarity regarding what actions you are authorized to perform but also prevents you from attempting actions that you do not have authorization to execute.
For more information on managing permissions within an organization and use of organization context switcher, see [Organizations](/cloud/concepts/identity-and-security/organizations/).
Each key is enforced at specific UI elements. For instance, the `Create Organization` key is enforced at the **Create Organization** button in the **Organizations** page. This implies that the button is disabled if you don't have the `Create Organization` assigned to a keychain, which, in turn, is assigned to a role that's associated with your user account for a given organization.
### Keys Management
#### View Keys
Review Keys assigned to your user account by navigating to the [Keys](https://cloud.layer5.io/security/keys) page.
Note
If you don’t have permission to view keys for your selected organization, you will see a disabled Keys tab. In that case, consider switching to a different organization for which you have permission to view keys, or contact your organization admin to assign you access to the keys page.
#### Review Key Usage
Keys themselves do not carry a usage counter - there is no "last used" column on the Keys page. What a key's use leaves behind is the event that the action itself produced, and those events are what you audit.
Every action a user takes is recorded on the [Audit Logs](https://cloud.layer5.io/events/audit) page, which answers *who did what, and when*:
- **User ID** - the account that performed the action, which is the account whose key was exercised.
- **Category** and **Action** - what was done, for example a workspace being created or a team being deleted. These correspond to the capability the key grants.
- **Acted Upon** - the resource the action was performed on.
- **Description** and **Created At** - the detail of the event and the time it occurred.
Filter by **Actor ID** to follow one user's activity, or by **Category** and **Action** to see everyone who exercised a particular capability over a period. Because keys are evaluated in the context of an organization, the log you are reading is the log for the organization you currently have selected.
Workspaces additionally keep their own activity log, scoped to that one workspace - see [View Recent Activity](/cloud/guides/workspaces/managing-workspaces/#view-recent-activity).
#### Assign Keys
1. Select the organization for which you wish to assign keys to users. You can do this by selecting the organization from the organization context switcher in the top navigation bar.
2. Navigate to [Keychains](https://cloud.layer5.io/security/keychains) page.
3. Choose from the existing set of keychains or create a new keychain to which you want to assign keys. For more information, see [Keychains](/cloud/concepts/identity-and-security/keychains/).
4. Choose one more of your desired keys from the list of available keys.
5. Navigate to the [Roles](https://cloud.layer5.io/security/roles) page.
6. Choose from the existing set of roles or create a new role to which you want to assign the keychain. For more information, see [Roles](/cloud/concepts/identity-and-security/roles/).
7. Navigate to [Users](https://cloud.layer5.io/identity/users) page.
8. Select the user to whom you want to assign the role with a new set of permissions. Alternatively, you can invite a new user and assign the role with the new set of permissions separately. For more information, see [Users](/cloud/concepts/identity-and-security/users/).
Note
If you don’t have permission to perform any of the above operations, consider switching to a different organization for which you are authorized to perform these actions. Alternatively, contact your organization admin for elevated access.
Permission Assignment at Teams, Organization and Provider Levels
- You need to have the default
Team Admin role (or a custom role with Edit User key assigned) to assign permissions to users in your team.
- You need to have the default
Organization Admin role (or a custom role with Edit User key assigned) to assign permissions to users in your organization.
- You need to have default
Provider Admin role (or a custom role with Update Profile key assigned) to assign permissions to users across any organization or teams.
### Keys Lifecycle
Layer5 Cloud ships with 103 default keys, each designed to enforce permissions across the platform. All the keys shipped with the system are immutable and cannot be deleted or modified. Each key is uniquely identified in the form of a UUID. The UUID is used to reference the key in the system.