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

feat(common): adding rbac support #354

Merged
merged 24 commits into from
Oct 4, 2024

Conversation

LarryGF
Copy link
Contributor

@LarryGF LarryGF commented Sep 5, 2024

Description of the change

  • Added support for RBAC objects (Role and RoleBinding)
  • Added template "bjw-s.common.lib.valuesToObject" with the purpose of eventually migrating all repeated *.valuesToObject templates to this.

Removed

Fixed

Added

  • You can create Roles and RoleBinding natively, which can be referenced by their identifiers
  • You can set a RoleBinding to bind to any of your existing ServiceAccounts by passing its identifier
  • With the new common.valuesToObject template you now can use the forceRename field to completely ignore the naming convention of your generated resources

Changed

Benefits

  • Native support for RBAC objects means that we don't have to rely on rawResources
  • Coupled with the multiple ServiceAccount support this means that we can be as granular as we want with the permissions in the chart
  • Assuming you're migrating from manifests or standard chart templates, using the forceRename field can allow for a seamless transition between your previously existing resources and the ones created by the chart (useful if, for instance, you're using ArgoCD and don't want it to delete your old resource and recreate it with a different name)

Possible drawbacks

  • I haven't been able to do extensive testing with this, so there might be some edge cases I missed

Applicable issues

  • fixes #

Additional information

Checklist

  • Title of the PR conforms to the Conventional Commits standard.
  • Scope of the of the PR title contains the chart name.
  • Chart version in Chart.yaml has been bumped according to Semantic Versioning.
  • Chart artifacthub.io/changes changelog annotation has been updated in Chart.yaml. See Artifact Hub documentation for more info.
  • Variables have been documented in the values.yaml file.

@bjw-s bjw-s changed the base branch from main to common-3.5.0 October 4, 2024 13:11
@bjw-s
Copy link
Owner

bjw-s commented Oct 4, 2024

I'm going to merge the PR as-is into the 3.5.0 branch, but I'm not sure if I'll keep the bjw-s.common.lib.valuesToObject template. I know all the separate functions are duplicating a bit of boilerplate, but my explicit intention with that function is to both convert and enrich the values to the "final" object. Because the enrichment will probably always be object-specific I don't think a generic function will really work there?

@bjw-s bjw-s merged commit f398239 into bjw-s:common-3.5.0 Oct 4, 2024
13 checks passed
@bjw-s
Copy link
Owner

bjw-s commented Oct 4, 2024

In retrospect I guess the object-specific enrichment could be moved into the render/* templates 🤔

@bjw-s bjw-s mentioned this pull request Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants