feat(operations/helm) add support for extraObjects

[timtalbot]

PR Description

Adds support for an extraObjects field in chart values to add additional manifests with chart installation.

Which issue(s) this PR fixes

Notes to the Reviewer

Following the model used by many charts including other Grafana ones to deploy extra objects with the chart. Thanks for your time!

PR Checklist

• CHANGELOG.md updated
• Documentation added
• Tests updated
• Config converters updated

[CLAassistant]

All committers have signed the CLA.

[tpaschalis]

Could you describe a couple of use cases where this could be useful?

This has come up in the past, but I'd like for us to pinpoint some real-world problems this is solving before introducing it simply because other charts do the same.

IMHO, this might be a footgun to users. How do we debug issues arising from people reusing values.yaml files they found online, or how do we deal with security concerns around having random objects reuse the agent's RBAC resources?

[timtalbot]

In my case, I'd like to deploy the agent to forward Prometheus metrics to an endpoint via basic auth using a configuration that mounts the password from a volume on the pod. I do see this chart already provides a way to mount extra volumes, but I'm using secrets-store-csi-driver-provider-aws to fetch a secret from AWS and mount it into a volume. I'm hoping to define the SecretProviderClass that will know how to retrieve my AWS secret as part of the agent installation itself so that one operation installs a totally working agent in my cluster. I'm deploying the agent into multiple clusters via Cluster API so it takes some workarounds to provide extra configuration to Helm installs that isn't provided via their charts.

I'll associate the service account to an AWS IAM role with an explicit list of permissions. That said I understand your security concerns. With this change, the user needs to understand and be responsible for what they're deploying with extraObjects. I sympathize that this complicates debugging if users are copy-paste deploying things they find online.

My own review?

[timtalbot]

A more straight forward example could be the ability to deploy an additional config map or secret to use with the agent.envFrom option that already exists as part of chart installation. Has that ever come up in past discussions?

[timtalbot]

@tpaschalis If there's little desire for this feature, I won't argue strongly otherwise. I've worked around it on my end. I appreciate your time looking at this regardless!

[tpaschalis]

Hey there, apologies for the belated response. For the time being, I'd like to hold off on this and reconsider if some other use case with no workaround.

[github-actions]

This PR has not had any activity in the past 30 days, so the needs-attention label has been added to it.
If you do not have enough time to follow up on this PR or you think it's no longer relevant, consider closing it.
The needs-attention label signals to maintainers that something has fallen through the cracks. No action is needed by you; your PR will be kept open and you do not have to respond to this comment. The label will be removed the next time this job runs if there is new activity.
Thank you for your contributions!

[QuentinBisson]

@tpaschalis The simplest use case I have is this:
How can I deploy a secret with this chart for let's say, connect to a secured endpoint like let's say grafana cloud?
Without creating the secret outside of the chart, how would you create this secret? Without this or another mechanism, then the chart is not self-sufficient