Oracle Cloud Infrastructure Documentation

Queue Policies

Use the Oracle Cloud Infrastructure Identity and Access Management (IAM) service to create policies  for your queues.

This topic covers details for writing policies to control access to the Queue service.

When writing policies, note that the Queue service supports authentication using the following methods:

  • User name and auth token: Supported for both the REST API and the STOMP protocol.
  • Instance principal: Supported for the REST API only (the compute instance must be assigned to a dynamic group).

Overview of Policy Syntax

The overall syntax of a policy statement is:

allow <subject> to <verb>
                    <resource-type> in <location> where <condition>

For example, you can specify:

  • A group or dynamic group by name or OCID as the <subject> . Or, you can use any-user to cover all users in the tenancy.

  • inspect, read, use, and manage as the <verb> to give a <subject> access to one or more permissions.

    As you go from inspect > read > use > manage, the level of access generally increases, and the permissions granted are cumulative. For example, use includes read plus the ability to update.

  • A family of resources such as virtual-network-family for the resource-type . Or, you can specify an individual resource in a family such as vcns and subnets.

  • A compartment by name or OCID as the <location> . Or, you can use tenancy to cover the entire tenancy.

  • One or more conditions in <condition> , which must be met for access to be granted. For multiple conditions, you can use any or all.

    A condition consists of one or more variables. A variable can be relevant to the request itself (for example, request.operation) or to the resource being acted upon in the request (for example, target.queue.id). To illustrate, to allow a group to manage a specific workspace and not any other workspace:

    allow group <group-name> to manage queues in compartment <compartment-name> where target.queue.id = '<queue-ocid>'

    Or, to allow a group to manage all Queue resources in the tenancy:

    allow group <group-name> to manage queues in tenancy

For more information about creating policies, see Getting Started with Policies and Policy Reference.

Resource-Types

To give users access to Queue resources, create IAM policies with Queue resource types.

For access to all Queue resources, use the queues resource type.

If you don't want users to manage queues, but you do want them to produce to a queue or consume from a queue, use the following individual resource types:

  • queue-push
  • queue-pull

See Policy Examples for more information.

Supported Variables

The Queue service supports all the general variables, plus those listed here.

For more information about general variables supported by OCI services, see General Variables for All Requests.

Variable Variable Type Source
target.queue.id Entity (OCID) Request
target.queue.name String Request

Details for Verbs + Resource-Type Combinations

There are various Oracle Cloud Infrastructure verbs and resource-types that you can use to create a policy.

The following tables show the permissions and API operations covered by each verb for Queue. The level of access is cumulative as you go from inspect to read to use to manage. A plus sign (+) in a table cell indicates incremental access compared to the cell directly above it, whereas "no extra" indicates no incremental access.

queue
Verbs Permissions APIs Fully Covered APIs Partially Covered
inspect

QUEUE_INSPECT

ListQueues

ListWorkRequests

ListWorkRequestErrors

ListWorkRequestLogs

none
read

INSPECT +

QUEUE_READ

INSPECT +

GetQueue

GetWorkRequest

GetStats

ListChannels

none
use

READ +

QUEUE_UPDATE

QUEUE_PRODUCE

QUEUE_CONSUME

READ +

UpdateQueue

PutMessages

GetMessages

UpdateMessage

DeleteMessage

none
manage

USE +

QUEUE_CREATE

QUEUE_DELETE

QUEUE_MOVE

USE +

CreateQueue

DeleteQueue

MoveQueue

none
queue-push
Verbs Permissions APIs Fully Covered APIs Partially Covered
inspect

none

none

none
read

none

none

none
use

QUEUE_PRODUCE

PutMessages

none
manage

none

none

none
queue-pull
Verbs Permissions APIs Fully Covered APIs Partially Covered
inspect

none

none

none
read

none

none

none
use

QUEUE_CONSUME

GetMessages

UpdateMessage

DeleteMessage

none
manage

none

none

none

Permissions Required for Each API Operation

The following table lists the API operations for Queue in a logical order, grouped by resource-type.

The resource-types are queues, queue-push, and queue-pull.

For information about permissions, see Permissions.

Required Permissions
API Operation Permissions Required to Use the Operation
ListQueues QUEUE_INSPECT
CreateQueue QUEUE_CREATE
GetQueue QUEUE_READ
DeleteQueue QUEUE_DELETE
MoveQueue QUEUE_MOVE
UpdateQueue QUEUE_UPDATE
ListWorkRequests QUEUE_INSPECT
GetWorkRequest QUEUE_READ
ListWorkRequestErrors QUEUE_INSPECT
ListWorkRequestLogs QUEUE_INSPECT
GetStats QUEUE_READ
ListChannels QUEUE_READ
PutMessages QUEUE_PRODUCE
GetMessages QUEUE_CONSUME
UpdateMessage QUEUE_CONSUME
DeleteMessage QUEUE_CONSUME
CreateConsumerGroup QUEUE_CONSUMER_GROUP_CREATE
DeleteConsumerGroup QUEUE_CONSUMER_GROUP_DELETE
GetConsumerGroup QUEUE_CONSUMER_GROUP_READ
UpdateConsumerGroup QUEUE_CONSUMER_GROUP_UPDATE
ListConsumerGroups QUEUE_CONSUMER_GROUP_INSPECT

Policies for Consumer Groups

Set the permissions so different people or apps can use queues and consumer groups the way they need.

You need to give permission for different teams or apps to do work with queue fanout and consumer groups. Here are some examples.

Allow Full Management of Queues and Consumer Groups

Use this if someone needs to do everything. make queues, turn on fanout, and manage all consumer groups. 

allow group QueueAdmins to manage queues in compartment <compartment-name>
allow group QueueAdmins to manage queue-consumer-groups in compartment <compartment-name>

Permissions Granted:

  • QUEUE_CONSUMER_GROUP_CREATE
  • QUEUE_CONSUMER_GROUP_UPDATE
  • QUEUE_CONSUMER_GROUP_DELETE
  • QUEUE_CONSUMER_GROUP_READ
  • QUEUE_CONSUMER_GROUP_INSPECT

Allow Read-Only Access to Consumer Groups

Use this when you want someone to only look at consumer groups and their settings—no changes allowed. 

 allow group QueueAuditors to inspect queue-consumer-groups in compartment <compartment-name>
allow group QueueAuditors to read queue-consumer-groups in compartment <compartment-name>

Permissions Granted:

  • QUEUE_CONSUMER_GROUP_INSPECT
  • QUEUE_CONSUMER_GROUP_READ

Allow Managing Consumer Groups but Not Queues

Use this for teams who organize and set up consumer groups and filters, but shouldn’t mess with the queues themselves. 

allow group FanoutOperators to manage queue-consumer-groups in compartment <compartment-name>

Permissions Granted:

  • QUEUE_CONSUMER_GROUP_CREATE
  • QUEUE_CONSUMER_GROUP_UPDATE
  • QUEUE_CONSUMER_GROUP_DELETE
  • QUEUE_CONSUMER_GROUP_READ
  • QUEUE_CONSUMER_GROUP_INSPECT

Allow Producers to Send Messages to Queues (No Consumer Group Access)

Use this for apps that just need to send (push) messages into a queue, but don’t read or see group details. 

allow dynamic-group QueueProducers to use queue-push in compartment <compartment-name>

Permissions Granted:

  • QUEUE_PRODUCE

Allow Consumers to Consume from a Specific Consumer Group

Use this for apps or teams that must only pull messages from a certain consumer group and not see any others. 

 allow dynamic-group AppConsumers to use queue-pull in compartment <compartment-name>
 where target.consumer-group.id = '<consumer_group_ocid>'

Permissions Granted:

  • QUEUE_CONSUME

Allow Consumers to Consume from Any Consumer Group in a Compartment

Use this when an app or service should pull messages from any group in the same compartment. 

allow dynamic-group SharedConsumers to use queue-pull in compartment <compartment-name>

Permissions Granted:

  • QUEUE_CONSUME

Allow Operators to Inspect Queues but Fully Manage Consumer Groups

Use these policies for people who need to see queue details and also want to fully organize consumer groups and filters. 

allow group FanoutOperators to inspect queues in compartment <compartment-name>
allow group FanoutOperators to manage queue-consumer-groups in compartment <compartment-name>

Permissions Granted:

  • Inspect queues
  • QUEUE_CONSUMER_GROUP_CREATE
  • QUEUE_CONSUMER_GROUP_UPDATE
  • QUEUE_CONSUMER_GROUP_DELETE
  • QUEUE_CONSUMER_GROUP_READ
  • QUEUE_CONSUMER_GROUP_INSPECT

Allow Queue Owners to Enable Fan-out but Delegate Consumer Group Management

Use this for teams where queue owners manage the queues, but app teams handle consumer group setup.

Queue owners:

allow group QueueOwners to manage queues in compartment <compartment-name>

Application teams:

allow group AppTeams to manage queue-consumer-groups in compartment <compartment-name>

Permissions Granted:

  • QUEUE_CONSUMER_GROUP_CREATE
  • QUEUE_CONSUMER_GROUP_UPDATE
  • QUEUE_CONSUMER_GROUP_DELETE
  • QUEUE_CONSUMER_GROUP_READ
  • QUEUE_CONSUMER_GROUP_INSPECT

Best Practices

  • Give each team or app only the permissions they need.
  • Use target.consumer-group.id to limit who can read from a group.
  • Keep producer, consumer, and fan-out manager roles separate if possible.
  • Only give full queue management access to those that need it.
  • Dynamic groups are useful for apps or automated services that need special permissions.

Policy Examples

Learn about Queue IAM policies using examples.

For administrators, the following policy lets the specified group do everything with queues and related Queue service resources:

Allow QueueManagers to manage queues in compartment <compartment_name>

Use the following policies to let a specified group produce to or consume from a queue:

Allow QueueProducers to use queue-push in compartment <compartment_name>
                
Allow QueueConsumers to use queue-pull in compartment <compartment_name>

Use the following policy to let a specified group inspect and read queue details:

Allow QueueReaders to read queues in compartment <compartment_name>