Support provider-only tags #32
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bbobrov
reviewed
Jun 30, 2025
keystone/common/policies/project.py
Outdated
| deprecated_reason=DEPRECATED_REASON, | ||
| deprecated_since=versionutils.deprecated.STEIN | ||
| ) | ||
| deprecated_create_project_provider_tags = policy.DeprecatedRule( |
There was a problem hiding this comment.
this and other deprecated rules are not needed
bbobrov
requested changes
Jun 30, 2025
There was a problem hiding this comment.
I have deployed this code to out qa cloud. Unfortunately, i got this reply when i tried to set project tag as a non-cloud-admin:
unsupported operand type(s) for +: 'set' and 'set' (HTTP 400) (Request-ID: req-3cbd86bd-920e-4f49-92e7-7f5443c2e58b)
Please see some other comments inline how i fixed it.
I am not sure that i fixed it correctly, because after i fixed it i could do
openstack project set --clear-tags <project-id>
And it cleared ptags even with non-cloud-admin-user; could you please also check this command as well?
joker-at-work
force-pushed
the
provider-tags
branch
from
38e400c to
e4bc1de
Compare
We want to set tags on projects that normal users cannot remove or edit. Instead, only operators of the cloud provider should be able to - hence we call them provider tags. We identify provider tags by matching on prefixes of tags. These prefixes are configurable via the `provider_tag_prefix` config option, which can bet set multiple times to have multiple prefixes. It's meant to be used e.g. like this "cloudname::special" with `provider_tag_prefix = cloudname::`. To make the roles allowed to edit these tags configurable, we introduce a new set of policies. Since these policies check additional restrictions on already existing actions, we extended existing actions with another layer ":provider_tags" added. A scheme like this is already in use a lot in Neutron to limit users being allowed to set certain attribute of e.g. networks. Since customers might not be aware of provider keys in their tooling, we allow them to send requests that change the tags they are allowed to edit while keeping the provider tags in tact - even if they aren't sent in the same request. This should make it easier for the customers to e.g. delete all their tags on a project while not having to filter in tags they don't care about. Change-Id: I9a144b1efdbd2481dcb929288a3fee97a4772279
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We want to set tags on projects that normal users cannot remove or edit. Instead, only operators of the cloud provider should be able to - hence we call them provider tags.
We identify provider tags by matching on prefixes of tags. These prefixes are configurable via the
provider_tag_prefixconfig option, which can bet set multiple times to have multiple prefixes. It's meant to be used e.g. like this "cloudname::special" withprovider_tag_prefix = cloudname::.To make the roles allowed to edit these tags configurable, we introduce a new set of policies. Since these policies check additional restrictions on already existing actions, we extended existing actions with another layer ":provider_tags" added. A scheme like this is already in use a lot in Neutron to limit users being allowed to set certain attribute of e.g. networks.
Since customers might not be aware of provider keys in their tooling, we allow them to send requests that change the tags they are allowed to edit while keeping the provider tags in tact - even if they aren't sent in the same request. This should make it easier for the customers to e.g. delete all their tags on a project while not having to filter in tags they don't care about.
Change-Id: I9a144b1efdbd2481dcb929288a3fee97a4772279