You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since in certain environments the infrastructure operators do not get accounts in RabbitMQ, I'd like to add a config switch that prohibits operator policies from being changed via HTTP API. Tentatively prohibit_remote_operator_policies=true
Broker will return a well-formed error to PUT /api/operator-policies, and the only way to set them becomes by accessing the host: either via rabbitmqctl, or #6687.
Perhaps extra work may be done to hide operator policies from 'policymaker's in the web console as well.
I briefly considered adding instead a new type of policies, say "global", to enforce cross-vhost limits. This feels a bit redundant, but I'm open to all arguments.
The text was updated successfully, but these errors were encountered:
How about then migrating default_policies.operator into operator_policies.default? With a bit of data transformation cuttlefish allows both mappings to co-exist.
Edit.
Or the opposite, since it's HTTP API, call the setting management.can_set_operator_policies instead? So far this one is my favourite.
Since in certain environments the infrastructure operators do not get accounts in RabbitMQ, I'd like to add a config switch that prohibits operator policies from being changed via HTTP API. Tentatively
prohibit_remote_operator_policies=true
Broker will return a well-formed error to
PUT /api/operator-policies
, and the only way to set them becomes by accessing the host: either via rabbitmqctl, or #6687.Perhaps extra work may be done to hide operator policies from 'policymaker's in the web console as well.
I briefly considered adding instead a new type of policies, say "global", to enforce cross-vhost limits. This feels a bit redundant, but I'm open to all arguments.
The text was updated successfully, but these errors were encountered: