Version: 7.x-35.0.0

Permissions and action groups

Hint: You can also use the Kibana Confguration GUI for configuring the Action Groups.

An action group is simply a collection of permissions with a telling name. Action groups are defined in the file sg_action_groups.yml and can be referred to in sg_roles.yml. Action groups can be nested.

Using action groups is the preferred way of assigning permissions to a role.

The file structure is very simple:

<action group name>:
  reserved: true|false #optional
  description: "..." #optional
  type: "index" #or cluster or kibana, is optional
    - '<permission or action group>'
    - '<permission or action group>'
    - ...


  type: "actionsgroups"
  config_version: 2
  reserved: false
    - "indices:data/read/search*"
    - "indices:data/read/msearch*"
  reserved: true
  description: "my other action group"
  type: "index"
    - "indices:data/read/suggest*"

Built-in action groups

Search Guard ships with a list of built-in action groups that are suitable for most use cases.


Name Description
SGS_UNLIMITED Grants complete access, can be used on index- and cluster-level. Equates to "*".

Index-level action groups

Name Description
SGS_INDICES_ALL Grants all permissions on the index. Equates to indices:*
SGS_READ Grants read permissions to read (but not search) data, and permissions to fetch field mappings.
SGS_SEARCH Grants permission to search documents. Includes SUGGEST.
SGS_DELETE Grants permission to delete documents
SGS_WRITE Grants write and delete permissions to documents
SGS_CRUD Combines the READ and WRITE action groups
SGS_GET Grants permission to use get and mget actions
SGS_SUGGEST Grants permission to use the suggest API. Already included in the READ action group.
SGS_CREATE_INDEX Grants permission to create indices and mappings
SGS_MANAGE_ALIASES Grants permission to manage aliases
SGS_INDICES_MONITOR Grants permission to execute all actions regarding index monitoring, e.g. recovery, segments info, index stats & status
SGS_MANAGE Grants all monitor and index administration permissions

Cluster-level action groups

Name Description
SGS_CLUSTER_ALL Grants all cluster permissions. Equates to cluster:*
SGS_CLUSTER_MONITOR Grants all cluster monitoring permissions. Equates to cluster:monitor/*
SGS_CLUSTER_COMPOSITE_OPS_RO Grants read-only permissions to execute multi requests like mget, msearch or mtv, plus permission to query for aliases.
SGS_CLUSTER_COMPOSITE_OPS Same as CLUSTER_COMPOSITE_OPS_RO, but also grants bulk write permissions and all aliases permissions.
SGS_MANAGE_SNAPSHOTS Grants full permissions to manage snapshots and repositories.

Multi- and bulk requests

To execute multi- and bulk requests, the respective user needs to have

  • multi and/or bulk permission on cluster level.
    • Assign the SGS_CLUSTER_COMPOSITE_OPS_RO or SGS_CLUSTER_COMPOSITE_OPS action group on cluster level
  • READ and/or WRITE permissions on index level
    • Assign the READ or WRITE action group on index level

For example, if a user executes a bulk request containing a delete request for index1 and an update request for index2, three permissions are required

  • SGS_CLUSTER_COMPOSITE_OPS on cluster level
  • SGS_DELETE permission for index1
  • SGS_WRITE permission for index2

Defining your own action groups

You can define your own action groups in sg_action_groups.yml. You can use any name you want. And you can also reference an action group from within another action group:

    - "indices:data/read/search*"
    - "indices:data/read/msearch*"
    - "indices:data/read/suggest*"

In this case, the action group MY_ACTION_GROUP includes the (wildcarded) search* and msearch* permissions, and also all permissions defined by the action group MY_OTHER_ACTION_GROUP.

You can then reference these action groups in the file sg_roles.yml simply by name:

    - index_patterns:
      - 'humanresources'

Not what you were looking for? Try the search.