Fix bundle role/rolebinding naming conflict

[kfox1111]

When you install a primary and a secondary deployment in the same Kubernetes cluster, use the same release name (spire), and configure the primary to give the bundle to the secondary, both releases want to own the same role/rolebinding name. This patch uses the same name as the configmap to ensure uniqueness.

[kfox1111]

Alternate approach to #309

[edwbuck]

Better than having it refer to a different name, adding a hard-coded suffix.

Thanks for the work.

(Can you close the alternative PR?)

[edwbuck]

@faisal-memon @marcofranssen @mrsabath or anyone else. Can we get a second review on this item, so it can be merged or reworked?

[faisal-memon]

What does the rendered name look like?

[kfox1111]

Its set the same as the configmap object its granting permissions to.
so, by default 'spire-bundle' or whatever the user overrides it to, such as 'spire-upstream-bundle'

[marcofranssen]

I have been trying to render the chart to see the endresult for myself.

$ git checkout role-conflict-fix-alt
$ helm template -n spire-system --values examples/production/values.yaml spire ./charts/spire | grep 'bundle' 
Error: template: spire/charts/spire-server/templates/pre-upgrade-hook.yaml:66:27: executing "spire/charts/spire-server/templates/pre-upgrade-hook.yaml" at <{{template "spire-lib.kubectl-image" (dict "appVersion" $.Chart.AppVersion "image" .Values.controllerManager.validatingWebhookConfiguration.upgradeHook.image "global" .Values.global "KubeVersion" .Capabilities.KubeVersion.Version)}}>: template "spire-lib.kubectl-image" not defined

Use --debug flag to render out invalid YAML

Seems like something is broken when defining values.yaml

Without it works, but that doesn't show me how it works for multiple.

$ helm template -n spire-system  spire ./charts/spire | grep 'bundle' 
        "trust_bundle_path": "/run/spire/bundle/bundle.crt",
# Source: spire/charts/spire-server/templates/bundle-configmap.yaml
  name: spire-bundle
            "k8sbundle": {
                "config_map": "spire-bundle",
# Role to be able to push certificate bundles to a configmap
  name: spire-bundle
    resourceNames: [spire-bundle]
  name: spire-bundle
  name: spire-bundle
            - name: spire-bundle
              mountPath: /run/spire/bundle
        - name: spire-bundle
            name: spire-bundle

Not sure why this change breaks it consistently, but on main branch it also randomly fails. Sometimes it succeeds, some times it fails. I guess the template rendering is kind of random from the perspective which resources are rendered first.

Update

Running it couple of times on this PR also gave me a successful run, but don't see the second bundle when grepping it.

$ helm template -n spire-system --values examples/production/values.yaml spire ./charts/spire | grep 'bundle' 
        "trust_bundle_path": "/run/spire/bundle/bundle.crt",
# Source: spire/charts/spire-server/templates/bundle-configmap.yaml
  name: spire-bundle
            "k8sbundle": {
                "config_map": "spire-bundle",
# Role to be able to push certificate bundles to a configmap
  name: spire-bundle
    resourceNames: [spire-bundle]
  name: spire-bundle
  name: spire-bundle
            - name: spire-bundle
              mountPath: /run/spire/bundle
        - name: spire-bundle
            name: spire-bundle

How do I test and check the impact of the resource naming using this change?

[kfox1111]

Its configured like: https://github.com/spiffe/helm-charts/pull/117/files#diff-40743f3e274c7e467663a938cef8fdd93afe9bfe23cf82d47bbd70dc756d92a3R4-R11

Its actually tested in that PR.

This pr doesn't make a second configmap. just makes sure the naming is unique when you have two instances of the chart.

[kfox1111]

Can we unblock this? The issue with the macro seems unrelated.

[faisal-memon]

What is the output of 'k get roles' and 'k get rolebindings' look like?

[marcofranssen]

LGTM 🚀

For reference, the problem I faced was due to running unittests locally,

That resulted into tgz files in the charts/spire/charts folder for all the subcharts. Those where generated from another branch. Therefore it didn't take the sourcecode for the dependencies and caused the conflict.

[kfox1111]

Ah. that makes sense. When we breakout the charts, we may want to add a .helmignore entry in the parent chart to to try and avoid that happening?