> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cube.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Member-level security

> Covers restricting which cubes, views, and members end users can query, including defaults and policy configuration with includes and excludes.

The data model serves as a facade of your data. With member-level security,
you can define whether [data model entities][ref-data-modeling-concepts] (cubes, views,
and their members) are exposed to end users and can be queried via [APIs &
integrations][ref-apis].

Member-level security in Cube is similar to column-level security in SQL databases.
Defining whether users have access to [cubes][ref-cubes] and [views][ref-views] is
similar to defining access to database tables; defining whether they have access
to dimensions and measures — to columns.

**By default, all cubes, views, and their members are *public*,** meaning that they
can be accessed by any users and they are also visible during data model introspection.

## Managing member-level access

You can use [access policies][ref-dap] to configure member-level access
for different groups. With the `access_policy` parameter in
[cubes][ref-ref-cubes] and [views][ref-ref-views], you can define which members
are accessible to users with specific groups.

Use the `member_level` parameter to specify either:

* `includes`: a list of allowed members, or
* `excludes`: a list of disallowed members

You can use `"*"` as a shorthand to include or exclude all members.

<Info>
  When you define access policies for specific groups, access is automatically denied to all other groups. You don't need to create a default policy that denies access.
</Info>

In the following example, member-level access is configured for different groups:

<CodeGroup>
  ```yaml title="YAML" theme={"dark"}
  views:
    - name: orders_view
      cubes:
        - join_path: orders
          includes:
            - status
            - created_at
            - count
            - count_7d
            - count_30d
      
      access_policy:
        # Managers can access all members except for `count`
        - group: manager
          member_level:
            excludes:
              - count
        
        # Observers can access all members except for `count` and `count_7d`
        - group: observer
          member_level:
            excludes:
              - count
              - count_7d
        
        # Guests can only access the `count_30d` measure
        - group: guest
          member_level:
            includes:
              - count_30d
  ```

  ```javascript title="JavaScript" theme={"dark"}
  view(`orders_view`, {
    cubes: [
      {
        join_path: orders,
        includes: [
          `status`,
          `created_at`,
          `count`,
          `count_7d`,
          `count_30d`
        ]
      }
    ],

    access_policy: [
      {
        // Managers can access all members except for `count`
        group: `manager`,
        member_level: {
          excludes: [
            `count`
          ]
        }
      },
      {
        // Observers can access all members except for `count` and `count_7d`
        group: `observer`,
        member_level: {
          excludes: [
            `count`,
            `count_7d`
          ]
        }
      },
      {
        // Guests can only access the `count_30d` measure
        group: `guest`,
        member_level: {
          includes: [
            `count_30d`
          ]
        }
      }
    ]
  })
  ```
</CodeGroup>

This configuration results in the following access:

| Group           | Access                                        |
| --------------- | --------------------------------------------- |
| `manager`       | All members except for `count`                |
| `observer`      | All members except for `count` and `count_7d` |
| `guest`         | Only the `count_30d` measure                  |
| All other users | No access to this view at all                 |

Access policies also respect member-level security restrictions configured via
`public` parameters. For more details, see the [access policies
reference][ref-dap-ref].

<Info>
  If you want to return masked values for restricted members instead of hiding
  them entirely, see [data masking][ref-data-masking] in access policies.
</Info>

[ref-data-modeling-concepts]: /docs/data-modeling/concepts

[ref-apis]: /reference

[ref-cubes]: /docs/data-modeling/cubes

[ref-views]: /docs/data-modeling/views

[ref-dap]: /docs/data-modeling/data-access-policies

[ref-ref-cubes]: /reference/data-modeling/cube

[ref-ref-views]: /reference/data-modeling/view

[ref-dev-mode]: /admin/connect-to-data#development-mode

[ref-playground]: /docs/workspace/playground

[ref-dap-ref]: /reference/data-modeling/data-access-policies

[ref-cubes-public]: /reference/data-modeling/cube#public

[ref-views-public]: /reference/data-modeling/view#public

[ref-measures-public]: /reference/data-modeling/measures#public

[ref-dimensions-public]: /reference/data-modeling/dimensions#public

[ref-hierarchies-public]: /reference/data-modeling/hierarchies#public

[ref-segments-public]: /reference/data-modeling/segments#public

[ref-dynamic-data-modeling]: /docs/data-modeling/dynamic

[ref-security-context]: /docs/data-modeling/access-control/context

[ref-data-masking]: /docs/data-modeling/data-access-policies#data-masking