Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Policy: Implement breaking change that Resource Mappings must be in a Resource Mapping Group #1625

Open
jakedoublev opened this issue Oct 9, 2024 · 2 comments
Labels
comp:policy Policy Configuration ( attributes, subject mappings, resource mappings, kas registry)

Comments

@jakedoublev
Copy link
Contributor

Background

Resource mapping groups have been implemented to support better organization of resource mappings. To reduce the complexity of the model we are making two breaking changes:

  1. Resource mappings are going to be considered adjacent to the policy so that they are never included as part of a namespaced export bundle
  2. Resource mappings cannot live without a resource mapping group

Acceptance Criteria

  • implement a migration strategy for this
  • document the change
  • update the protos
  • update the CLI
@jakedoublev jakedoublev added the comp:policy Policy Configuration ( attributes, subject mappings, resource mappings, kas registry) label Oct 9, 2024
@strantalis
Copy link
Member

@jakedoublev What is a resource mapping group?

@jakedoublev
Copy link
Contributor Author

@strantalis Resource Mapping Groups are a concept that allow association of a bunch of resource mappings in a bunch. A tagging vendor could publish a set of resource mappings (as a group) that map their internal software's tags to known policy attributes. See ADR: #1209 and Epic: #1255

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
comp:policy Policy Configuration ( attributes, subject mappings, resource mappings, kas registry)
Projects
None yet
Development

No branches or pull requests

2 participants