Access Control
This section of the documentation covers what a user is allowed to see and do after successfully authenticating.
Concepts
| Term | Description |
|---|---|
| Permission | An individual action, such as creating an index (e.g. indices:admin/create). For a complete list, see Permissions. |
| Action group | A set of permissions. For example, the predefined SEARCH action group authorizes roles to use the _search and _msearch APIs. |
| Role | Security roles define the scope of a permission or action group: cluster, index, document, or field. For example, a role named delivery_analyst might have no cluster permissions, the READ action group for all indices that match the delivery-data-* pattern, access to all document types within those indices, and access to all fields except delivery_driver_name. |
| Backend role | (Optional) Arbitrary strings that you specify or that come from an external authentication system (e.g. LDAP/Active Directory). Backend roles can help simplify the role mapping process. Rather than mapping a role to 100 individual users, you can map the role to a single backend role that all 100 users share. |
| User | An individual using Circonus. A user has credentials (e.g. a username and password), zero or more backend roles, and zero or more custom attributes. |
| Role mapping | Users assume roles after they successfully authenticate. Role mappings, well, map roles to users (or backend roles). For example, a mapping of circonus_user (role) to jdoe (user) means that John Doe gains all the permissions of circonus_user after authenticating. Likewise, a mapping of all_access (role) to admin (backend role) means that any user with the backend role of admin gains all the permissions of all_access after authenticating. You can map each role to many users and/or backend roles. |