Allow user to define a "default" `sources.yml`

flavio commented 2 years ago

The problem

Now that we moved to rustls, system certificates are ignored by kwctl. Because of that, pushing and pulling from registries using self-signed certificates need some extra hops: all the run, pull and push commands must be invoked using the --sources-path flag.

The same applies to interactions with registries that are not secured with TLS. But this is a problem that happened also before the move to rustls.

Desired workflow

As a user, I want to define a sources.yml file somewhere inside of my home directory. kwctl should then use it by default whenever I invoke a command that has the --sources-path flag.

The desired outcome is to not force the user to specify this flag every time.

However, the user must still be able to provide a different sources.yml.

The sources.yml file should be stored under the user's home directory, inside of a "configuration" path.

Acceptance criteria

kwctl looks for this configuration file before running a command that has the --sources-path flag
If the file is not found, no error is raised
If the file exists, its contents are silently loaded. Errors caused by wrong values are obviously raised
If the user provides a sources.yml file via the --sources-path flag, the $HOME/<config path>/sources.yml file is ignored. Only the contents from the "flag defined" file are used
The documentation of kwctl is updated to explain the user where this file is located

jvanz commented 2 years ago

Is there any reason to call the file sources.yml ? Am I missing some standard ? Or is this a share config fille that I'm not aware?

I think we can take this opportunity to create configuration file to kwctl, like $HOME/.config/kwctl or similar. Therefore, in the future if we need to add more configs we already have a file with a nice name.

flavio commented 2 years ago

We already have a sources.yml file format that can be used via the dedicated cli flag. I would prefer to not conflate that into a bigger configuration file.

I think this approach has several benefits:

end user: they can copy a sources.yml they already have to/from this ~/.kubectl path
end user: the purpose of the file is clear. There's a 1:1 mapping with the cli flags
end user/ & us: the doc has to cover just one file format (the sources.yml) instead of two (the sources.yml and the ~/.kubectl/config.yml one)
us: we don't have to define and maintain new structs to parse this new ~/.kubectl/config.yml file

ereslibre commented 2 years ago

I agree with @flavio.

Keeping them separate helps to separate policy sources:

Case 1: this server is insecure and I'm good with it, as I'm developing and I don't want to mess with PKI right now.
Case 2: this server presents a certificate coming from a private CA. I trust it if it matches the chain.

The --docker-config-json-path is a subset of docker-config-json(5) where you can specify authentication details for registries.

They are different beasts in my opinion and it would be good to keep them separate. As for the name of sources.yaml... is the one we came up with at the beginning given it's the sources of policies. Maybe it wasn't very good... I don't have a better option right now though; naming is hard 🙈

raulcabello commented 2 years ago

This is already implemented or am I missing something here? https://github.com/kubewarden/kwctl/blob/main/src/main.rs#L399-L401 sources.yaml will be loaded if it is placed here $HOME/.config/kubewarden/sources.yaml I created a registry with a self signed certificate and verified the sources.yaml was loaded from $HOME/.config/kubewarden/sources.yaml or the cli argument if provided

ereslibre commented 2 years ago

This is already implemented or am I missing something here? https://github.com/kubewarden/kwctl/blob/main/src/main.rs#L399-L401

As I understand the issue, it's true, it's already implemented. Sorry 🤦

kubewarden / kwctl