Documentazione di Oracle Cloud Infrastructure

Criteri coda

Utilizzare il servizio Oracle Cloud Infrastructure Identity and Access Management (IAM) per creare criteri per le code.

In questo argomento vengono descritti i dettagli per la scrittura dei criteri per controllare l'accesso al servizio Coda.

Quando si scrivono i criteri, tenere presente che il servizio Queue supporta l'autenticazione utilizzando i metodi riportati di seguito.

  • Nome utente e token di autenticazione: sono supportati sia per l'API REST che per il protocollo STOMP.
  • Principal istanza: supportato solo per l'API REST (l'istanza di computazione deve essere assegnata a un gruppo dinamico).

Panoramica della sintassi dei criteri

Di seguito è riportata la sintassi generale di un'istruzione criterio.

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

Ad esempio, è possibile specificare quanto riportato di seguito.

  • Gruppo o gruppo dinamico per nome o OCID come <subject> . In alternativa, è possibile utilizzare any-user per coprire tutti gli utenti nella tenancy.

  • inspect, read, use e manage come <verb> per concedere a <subject> l'accesso a una o più autorizzazioni.

    Quando si passa da inspect > read > use > manage, il livello di accesso generalmente aumenta e le autorizzazioni concesse sono cumulative. Ad esempio, use include read oltre alla possibilità di eseguire l'aggiornamento.

  • Una famiglia di risorse come virtual-network-family per resource-type . In alternativa, è possibile specificare una singola risorsa in una famiglia come vcns e subnets.

  • Compartimento in base al nome o all'OCID come <location> . In alternativa, è possibile utilizzare tenancy per coprire l'intera tenancy.

  • Una o più condizioni in <condition> , che devono essere soddisfatte affinché l'accesso sia concesso. Per più condizioni, è possibile utilizzare any o all.

    Una condizione è costituita da una o più variabili. Una variabile può essere rilevante per la richiesta stessa (ad esempio, request.operation) o per la risorsa su cui si agisce nella richiesta (ad esempio, target.queue.id). Per illustrare, per consentire a un gruppo di gestire un'area di lavoro specifica e non un'altra area di lavoro:

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

    In alternativa, per consentire a un gruppo di gestire tutte le risorse Coda nella tenancy:

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

Per ulteriori informazioni sulla creazione dei criteri, consulta la Guida introduttiva ai criteri e il riferimento ai criteri.

Resource-Types

Per concedere agli utenti l'accesso alle risorse della coda, creare criteri IAM con i tipi di risorsa Coda.

Per accedere a tutte le risorse della coda, utilizzare il tipo di risorsa queues.

Se non si desidera che gli utenti gestiscano le code, ma si desidera che vengano prodotte in una coda o utilizzate da una coda, utilizzare i tipi di risorsa seguenti:

  • queue-push
  • queue-pull

Per ulteriori informazioni, vedere Esempi di criteri.

Variabili supportate

Il servizio Queue supporta tutte le variabili generali, oltre a quelle elencate qui.

Per ulteriori informazioni sulle variabili generali supportate dai servizi OCI, vedere Variabili generali per tutte le richieste.

Variabile Tipo di variabile Origine
target.queue.id Entità (OCID) Richiedi
target.queue.name Stringa Richiedi

Dettagli per le combinazioni verbi-tipo di risorsa

Esistono vari verbi e tipi di risorse di Oracle Cloud Infrastructure che è possibile utilizzare per creare un criterio.

Le tabelle seguenti mostrano le autorizzazioni e le operazioni API coperte da ciascun verbo per la coda. Il livello di accesso è cumulativo quando si passa da inspect a read a use a manage. Un segno più (+) in una cella di tabella indica l'accesso incrementale rispetto alla cella direttamente sopra di essa, mentre "nessun extra" indica nessun accesso incrementale.

queue
Verbi Autorizzazioni API completamente coperte API parzialmente coperte
ispezionare

QUEUE_INSPECT

ListQueues

ListWorkRequests

ListWorkRequestErrors

ListWorkRequestLogs

nessuno
letto

ISPEZIONA +

QUEUE_READ

ISPEZIONA +

GetQueue

GetWorkRequest

GetStats

ListChannels

nessuno
utilizzare

LETTO +

QUEUE_UPDATE

QUEUE_PRODUCE

QUEUE_CONSUME

LETTO +

UpdateQueue

PutMessages

GetMessages

UpdateMessage

DeleteMessage

nessuno
gestisci

USE +

QUEUE_CREATE

QUEUE_DELETE

QUEUE_MOVE

USE +

CreateQueue

DeleteQueue

MoveQueue

nessuno
queue-push
Verbi Autorizzazioni API completamente coperte API parzialmente coperte
ispezionare

nessuno

nessuno

nessuno
letto

nessuno

nessuno

nessuno
utilizzare

QUEUE_PRODUCE

PutMessages

nessuno
gestisci

nessuno

nessuno

nessuno
queue-pull
Verbi Autorizzazioni API completamente coperte API parzialmente coperte
ispezionare

nessuno

nessuno

nessuno
letto

nessuno

nessuno

nessuno
utilizzare

QUEUE_CONSUME

GetMessages

UpdateMessage

DeleteMessage

nessuno
gestisci

nessuno

nessuno

nessuno

Autorizzazioni necessarie per ogni operazione API

Nella tabella seguente sono elencate le operazioni API per la coda in ordine logico, raggruppate per tipo di risorsa.

I tipi di risorsa sono queues, queue-push e queue-pull.

Per informazioni sulle autorizzazioni, vedere Autorizzazioni.

Autorizzazioni necessarie
Operazione API Autorizzazioni necessarie per utilizzare l'operazione
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

Criteri per gruppi di consumer

Imposta le autorizzazioni in modo che persone o applicazioni diverse possano utilizzare code e gruppi di consumer nel modo desiderato.

È necessario concedere l'autorizzazione a team o app diversi per eseguire il lavoro con fanout della coda e gruppi di consumer. Di seguito vengono riportati alcuni esempi.

Consenti gestione completa code e gruppi di consumer

Utilizzare questa opzione se qualcuno deve eseguire tutte le operazioni. Creare code, attivare il fanout e gestire tutti i gruppi di consumer. 

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

Autorizzazioni concesse:

  • QUEUE_CONSUMER_GROUP_CREATE
  • QUEUE_CONSUMER_GROUP_UPDATE
  • QUEUE_CONSUMER_GROUP_DELETE
  • QUEUE_CONSUMER_GROUP_READ
  • QUEUE_CONSUMER_GROUP_INSPECT

Consenti accesso in sola lettura ai gruppi di consumer

Utilizzare questa opzione quando si desidera che qualcuno esamini solo i gruppi di consumer e le relative impostazioni, senza modifiche consentite. 

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

Autorizzazioni concesse:

  • QUEUE_CONSUMER_GROUP_INSPECT
  • QUEUE_CONSUMER_GROUP_READ

Consenti gestione gruppi di consumatori ma non code

Utilizzare questa opzione per i team che organizzano e impostano gruppi di consumer e filtri, ma non devono interferire con le code stesse. 

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

Autorizzazioni concesse:

  • QUEUE_CONSUMER_GROUP_CREATE
  • QUEUE_CONSUMER_GROUP_UPDATE
  • QUEUE_CONSUMER_GROUP_DELETE
  • QUEUE_CONSUMER_GROUP_READ
  • QUEUE_CONSUMER_GROUP_INSPECT

Consenti ai producer di inviare messaggi alle code (nessun accesso al gruppo di consumer)

Utilizzare questa opzione per le app che devono solo inviare messaggi (push) in una coda, ma non leggere o visualizzare i dettagli del gruppo. 

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

Autorizzazioni concesse:

  • QUEUE_PRODUCE

Consenti consumo consumatori da un gruppo di consumatori specifico

Utilizzare questa opzione per le applicazioni o i team che devono estrarre i messaggi solo da un determinato gruppo di consumer e non visualizzarne altri. 

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

Autorizzazioni concesse:

  • QUEUE_CONSUME

Consenti consumo da qualsiasi gruppo di consumatori in un compartimento

Utilizzare questa opzione quando un'applicazione o un servizio deve estrarre i messaggi da qualsiasi gruppo nello stesso compartimento. 

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

Autorizzazioni concesse:

  • QUEUE_CONSUME

Consenti agli operatori di ispezionare le code ma gestisci completamente i gruppi di consumatori

Utilizzare questi criteri per le persone che devono visualizzare i dettagli della coda e che desiderano organizzare in modo completo gruppi e filtri di consumer. 

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

Autorizzazioni concesse:

  • Ispeziona code
  • QUEUE_CONSUMER_GROUP_CREATE
  • QUEUE_CONSUMER_GROUP_UPDATE
  • QUEUE_CONSUMER_GROUP_DELETE
  • QUEUE_CONSUMER_GROUP_READ
  • QUEUE_CONSUMER_GROUP_INSPECT

Consenti ai proprietari delle code di abilitare il fan-out ma delega la gestione dei gruppi di consumer

Utilizzare questa opzione per i team in cui i proprietari delle code gestiscono le code, ma i team delle applicazioni gestiscono l'impostazione dei gruppi di consumer.

Proprietari coda:

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

Team applicativi:

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

Autorizzazioni concesse:

  • QUEUE_CONSUMER_GROUP_CREATE
  • QUEUE_CONSUMER_GROUP_UPDATE
  • QUEUE_CONSUMER_GROUP_DELETE
  • QUEUE_CONSUMER_GROUP_READ
  • QUEUE_CONSUMER_GROUP_INSPECT

Procedure ottimali

  • Dai a ogni team o app solo le autorizzazioni di cui hanno bisogno.
  • Utilizzare target.consumer-group.id per limitare gli utenti che possono leggere da un gruppo.
  • Mantieni separati, se possibile, i ruoli di producer, consumer e fan-out manager.
  • Offri accesso completo alla gestione delle code solo a coloro che ne hanno bisogno.
  • I gruppi dinamici sono utili per applicazioni o servizi automatizzati che richiedono autorizzazioni speciali.

Esempi di criteri

Informazioni sui criteri IAM della coda mediante esempi.

Per gli amministratori, il criterio riportato di seguito consente al gruppo specificato di eseguire tutte le operazioni con le code e le risorse correlate del servizio Coda.

Allow QueueManagers to manage queues in compartment <compartment_name>

Utilizzare i criteri riportati di seguito per consentire a un gruppo specificato di produrre o consumare da una coda.

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

Utilizzare il seguente criterio per consentire a un gruppo specificato di ispezionare e leggere i dettagli della coda:

Allow QueueReaders to read queues in compartment <compartment_name>