Allow users to provide credentials for Helm Charts

[dbw7]

Introduces auth.yaml where users are able are able to provide credentials for Helm charts in the following format:

helm:
  - url: https://releases.rancher.com/server-charts/stable
    credentials:
      username: test
      password: test
  - url: https://charts.jetstack.io
    credentials:
      username: test2
      password: test2

The way it functions is the user creates the file above, and if we detect the user has provided credentials for a Helm chart that is to be created as a CRD, we append

authSecret:
        name: $CHARTNAME-storage-auth

And then we create the corresponding secret file $CHARTNAME-auth-repo-auth.yaml (Naming needs to be fixed)

The main purpose of this PR is

type HelmAuth struct {
   URL      string `yaml:"url"`
   Credentials Credentials `yaml:"credentials"`
}

Please let me know if this PR makes sense and follows the paradigms you guys look for.

[dirkmueller]

why did you choose to do this over the kuberentes/helm api of defining "secrets" with a name that can be then referenced on either helm or other oci artifacts? we also need to have secrets for fetching UC images itself for example. am I misunderstanding something?

[dbw7]

Can you elaborate a bit more on what that would look like? The reason I choose to do it this way is it allows the user to easily provide their credentials in a way that we can utilize in multiple different ways. The current implementation is just for Helm charts but I designed it in a way that it will be easily extendable to grabbing container images. Additionally, this also sets it up for the future when/if we are looking at air-gapping artifacts, where the credentials can be used to grab all the artifacts early.

[frelon]

If you could rebase on main and add code for writing the helm auth-file in internal/config/v0/config.go

As well as some example auth values in internal/cli/action/init.go I would be much obliged! 🙏

[ipetrov117]

Thanks for your efforts on this 🚀

I left out some comments on things I am not entirely clear on. Let me know what you think!

[dirkmueller]

Can you elaborate a bit more on what that would look like? The reason I choose to do it this way is it allows the user to easily provide their credentials in a way that we can utilize in multiple different ways. The current implementation is just for Helm charts but I designed it in a way that it will be easily extendable to grabbing container images. Additionally, this also sets it up for the future when/if we are looking at air-gapping artifacts, where the credentials can be used to grab all the artifacts early.

I understand, but how is that different when you have a secrets abstraction (e.g. a secrets.yaml that contains all the abstractions) and all other yaml files only refer to that one?

I think it is much easier to censor a support tarball for example by just dropping the secrets.yaml over having to edit multiple yaml files all ove rthe place to remove the secrets before posting them online.

I don't understand why they need to be embedded alongside everything else rather than isolated into a file and then having a simple lookup mechanism? what am I missing?

[ipetrov117]

I understand, but how is that different when you have a secrets abstraction (e.g. a secrets.yaml that contains all the abstractions) and all other yaml files only refer to that one?

I think it is much easier to censor a support tarball for example by just dropping the secrets.yaml over having to edit multiple yaml files all ove rthe place to remove the secrets before posting them online.

I don't understand why they need to be embedded alongside everything else rather than isolated into a file and then having a simple lookup mechanism? what am I missing?

IMO this comes down to preference and which UX we want to make easier. I do not think that "editing multiple yaml files all over the place" is avoidable. We just need to reduce the chance of it needing to be done.

Let's take the "single isolated credentials file" (e.g. secrets.yaml/auth.yaml) thesis for example. If we go down this route, the "editing multiple yaml files all over the place" will come from the fact that for each private resource, the user would have to jump between:

1. kubernetes/cluster.yaml - for defining local Helm repositories
2. release.yaml - for defining Helm charts coming from the release manifest
3. The release manifest itself - for retrieving the necessary URL to which this credentials map to
4. The secrets.yaml / auth.yaml unified credentials file - for actually defining the credentials

From my PoV this will be very prone to user error, as this involves jumping through multiple files during configuration definition. Furthermore, we should also not disregard the fact that we will be introducing a new configuration file. Our users struggle with the number of files as it is today, adding another one will just pile onto that frustration.

Now on the other side of the coin is "embedding the credentials next to the resource definition" thesis. Here, as you already mentioned, the "editing multiple yaml files all over the place" will come when users need to censor a support tarball. So, the "jumping" will not happen during configuration definition, but only when a problem that requires support intervention, happens. From my PoV this significantly reduces the initial user stress during configuration definition. Mainly because:

1. Users will provide credentials where they configure the resource - no file jumping during definition -> less chance for configuration errors -> less frustration
2. Users will not have to manually create files, but instead will just provide their credentials for the resource and we will handle the rest:
   • we will map the credentials to the URLs
   • we will setup the necessary secrets
   • we will place the in the correct place
   • we will ensure that everything is setup as it should for deployment

As I said in the beginning, IMO it comes down to tradeoffs - do we have the user jump through multiple files during configuration (e.g. isolated file thesis), or do we have the user only do the "jumping" if a serious problem that requires outside intervention occurs (e.g. embedded configuration thesis).

To me, the "embedded configuration" thesis makes more sense, as it will require less "jumping" during configuration, hence less possible errors. Let me know what I am missing.

[dirkmueller]

Let's take the "single isolated credentials file" (e.g. secrets.yaml/auth.yaml) thesis for example. If we go down this route, the "editing multiple yaml files all over the place" will come from the fact that for each private resource, the user would have to jump between:

1. kubernetes/cluster.yaml - for defining local Helm repositories
2. release.yaml - for defining Helm charts coming from the release manifest
3. The release manifest itself - for retrieving the necessary URL to which this credentials map to
4. The secrets.yaml / auth.yaml unified credentials file - for actually defining the credentials

I am not sure I get that. The core and product release manifest define repositories, each with a name:

    repositories:
    - name: metallb
      url: https://metallb.github.io/metallb
    - name: suse-edge
      url: https://suse-edge.github.io/charts

The user doesn't have to modify anything there. the only thing they have to do is in the secrets.yaml to define their secrets for the indivudual repositories. example below:

cat secrets.yaml
  secrets:
  - name: metallb
    user: ..
    password: ...
  - name: suse-edge
    user: ..
    password: ..
  - name: rancher-charts-secret
    user: ..
    password: ..

No modification are needed on release manifest, because if we know these are behind access control, they would already be defining a "secret: " link for example. we could even decide to make it implicitly linked via the repository name. if a chart or resource repository does not require authentication, that would be optional and no extra work needed.

From my PoV this will be very prone to user error, as this involves jumping through multiple files during configuration definition. Furthermore, we should also not disregard the fact that we will be introducing a new configuration file. Our users struggle with the number of files as it is today, adding another one will just pile onto that frustration.

If that's a concern, we can define the "secrets" as part of "release.yaml" also. My main point is to not sprinkle secrets across many files, but centralize it in one location. having the file separate means we can easily remove it from "exports" for supportability purposes. The other advantage is that users who use private infrastructure can define their "private-registry" secret and use that everywhere, not falling out of sync (following DRY principle).

Now on the other side of the coin is "embedding the credentials next to the resource definition" thesis. Here, as you already mentioned, the "editing multiple yaml files all over the place" will come when users need to censor a support tarball. So, the "jumping" will not happen during configuration definition, but only when a problem that requires support intervention, happens. From my PoV this significantly reduces the initial user stress during configuration definition.

Which is important, because when a support tarball is needed there is also going to be "stress", and it is unplanned.

1. Users will provide credentials where they configure the resource - no file jumping during definition -> less chance for configuration errors -> less frustration

if the same resource is used in multiple places, the resource authentication information is duplicated. Also, users might be deploying from a gitops paradigm where the secrets are in a different sensitivity domain. All the customization could be managed in git when the secrets are separated, or the secrets are encrypted in a separate secrets store.

2. Users will not have to manually create files, but instead will just provide their credentials for the resource and we will handle the rest:

That's the case in both cases?

As I said in the beginning, IMO it comes down to tradeoffs - do we have the user jump through multiple files during configuration (e.g. isolated file thesis), or do we have the user only do the "jumping" if a serious problem that requires outside intervention occurs (e.g. embedded configuration thesis).

Most security guidelines (NIST 800-53, ISO 27001, PCI-DSS) require separation of secrets from configuration data. managing them in place means our solution cannot be compliant with that.

We will eventually have to offer the option to encrypt secrets for configuration management, and keeping them separate makes that a little bit less awkward imho.

[ipetrov117]

For the thread's context - we have agreed to keep the implementation as it is and integrate over it should user requirements arise. With that in mind I left a couple of comments, let me know what you think!

[ipetrov117]

Great work on this! I think these are my last batch of comments. Once we discuss them, I'll be happy to approve.