# Managing Permissions

## Understanding Permissions

Version: 25.07

NextGen Object Storage provides 2 levels of permissions: Account and Container.

Both permissions types are enforced on account members only, account
admins always have all permissions.

**Account-level** permissions control access to containers and objects within an account.
The following account-level permissions are available:

| **Permission**    | **Description**                                                                                                                                                        |
|-------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| List Containers   | Can list/HEAD Containers                                                                                                                                               |
| Create Containers | Can create containers, modify container metadata, and perform HEAD on<br/>containers (includes operations such as PUT bucket logging,<br/>PUT bucket lifecycle, etc.). |
| Delete Containers | Can perform HEAD and DELETE on containers. Cannot delete objects.                                                                                                      |
| Read Objects      | Can perform HEAD/GET/LIST on objects and HEAD on containers.                                                                                                           |
| Write Objects     | Can PUT/POST objects and perform HEAD on containers.                                                                                                                   |
| Delete Objects    | Can DELETE objects and perform HEAD on containers.                                                                                                                     |

**Container-level** permissions control access to objects within a container.
The following container-level permissions are available:

| **Permission**   | **Description**                                                         |
|------------------|-------------------------------------------------------------------------|
| Read             | Can GET, HEAD, and LIST objects, and perform HEAD on the<br/>container. |
| Write            | Can PUT and POST objects.                                               |
| Delete           | Can DELETE objects. Cannot delete the container itself.                 |

**Default Permissions:**

An account is created with default account-level permissions that
allow all account members to list/create/delete containers in the
account.

After an account is created, account-level permissions can be
set by a NextGen Object Storage Admin or an Account Admin.

After a container is created, container-level permissions can be set
by a NextGen Object Storage Admin or an Account Admin.

<a id="setting-account-permissions"></a>

## Setting Account Permissions

Scope: Account Administrator

Account-level permissions are set in the **Account** view Details pane,
and can be set globally for all users in an account or per-user.

* For global account permissions, check the desired permissions for
  **All Members** in the details pane at the bottom of the Accounts view
  and then click **Save**.
* For per-user account permissions, click **Add** in the toolbar on top
  of the Details pane. In the **Set Permissions** dialogue which opens,
  individually select the desired permissions per user and then
  click **Save**.

<a id="setting-container-permissions"></a>

### Setting Container Permissions

Scope: Account Administrator

Container-level permissions are set in the **Console** view Details pane,
and can be set globally for all users in an account or per-user.

* For global container permissions, select the desired container
  in the Container pane at the top of the Console view.  Then select the
  desired permissions in the Details pane in the **All Users** row or
  **All Authenticated Members** row and click **Save**.
* For per-user container permissions, click **Add** in the toolbar on top
  of the Details pane. In the **Set Permissions** dialogue which opens,
  individually select the desired permissions per user and then
  click **Save**.

### Cross-Origin Resource Sharing (CORS)

Version: 23.09-SP1

Scope: Account Administrator

Cross-Origin Resource Sharing (CORS) is a security standard that enables
servers to specify safe origins from which browsers are allowed to request
resources.

CORS is an extension based on the Same-Origin Policy (SOP) that browsers
use to prevent malicious applications from accessing sensitive data on
domains beyond their control. SOP is a browser security feature that
restricts how resources can be accessed by different web applications.
It requires that a resource must be from the same origin as the web
application that is attempting to access it.

#### SOP

For two origins to be considered the same, they must have the same domain
and URI scheme. If a port is specified, then the ports of both origins must
match. The URL path and query components are irrelevant for SOP purposes.

Example of SOP compliance:

* Origin 1: `https://example.com/example1/index.html`
* Origin 2: `https://support.example.com/faqs.html`

In this example, the scheme is `https` and the domain is `example.com`,
and both are the same for both origins.

Example of SOP non-compliance:

* Origin 1: `https://example.com/example1/index.html`
* Origin 2: `http://example.com/example1/index.html`

  Although the domain is identical to Origin 1,
  the `http` scheme differs from `https`.
* Origin 3: `http://example.com:1030/example1/index.html`

  Although the scheme and domain are identical to Origin 2,
  the specified port differs from no port specified in Origin 2.
* Origin 4: `http://examples.com:1030/example1/index.html`

  Although the scheme and port are identical to Origin 3,
  the domain `examples.com` differs from `example.com`.

#### CORS

CORS enables client-side web applications that are loaded in one domain to
interact with resources in a different domain.
Using CORS support, you can build client-side web applications and specify
the permitted cross-origin access to your resources.

To configure a bucket to allow cross-origin requests, add a CORS
configuration to the bucket.
See [CORS configuration examples](object-storage-clients.md#ngos-aws-cli-cors-examples).

The CORS configuration is a set of rules on a bucket that:

* Identifies the origins that are allowed access to the bucket
* The HTTP methods (operations) supported for each origin,
  together with operation-specific information