Add CLI command for Config

[radcortez]

Adds a top-level Config CLI with two subcommands:

• Set
  • Can Add, Update and Remove a configuration from application.properties
  • Will encrypt the value with the -k flag.
• Encryptor
  • Can encrypt arbitrary values in AES/GCM/NoPadding (will support more algorithms)

• Fixes Integrate FileVault Utils with Quarkus CLI #29172

Requires SmallRye Config 3.4.x (still to be released).

[maxandersen]

Could this not be a quarkus plugin that is contributed by relevant extension?

/Cc @iocanel

[sberyozkin]

Great stuff @radcortez, thanks for this PR, I have a few comments, but looks like a perfect start, cheers

[iocanel]

Could this not be a quarkus plugin that is contributed by relevant extension?

/Cc @iocanel

Yeah. AFAIR I have created a PR for the file vault extension that contributed a CLI plugin: quarkiverse/quarkus-file-vault#67. Don't recall why it wasn't merged but we could definitely do it like that.

[sberyozkin]

@iocanel Yeah, I recall the PR, thanks for opening it, the reason it was not merged was because it is in the Quarkiverse extensions, but now it evolves in the Quarkus CLI

[radcortez]

Would you like us to move this outside the main CLI? Since this is Config related, all the Config integration is done at the core level, so there is no Config extension to add this. The file vault behaviour is now provided by SmallRye Config core and a couple of dependencies: SmallRye Config Source Keystore and SmallRye Config Crypto.

[maxandersen]

Would you like us to move this outside the main CLI? Since this is Config related, all the Config integration is done at the core level, so there is no Config extension to add this. The file vault behaviour is now provided by SmallRye Config core and a couple of dependencies: SmallRye Config Source Keystore and SmallRye Config Crypto.

ah! that is a good point - I hadn't thought about it from that perspective. I somehow thought it was only relevant for OIDC /security stuff but yeah it is not really.

[maxandersen]

okey so if we want it in the default quarkus cli it needs to actually "fit".

what is the actual usage pattern here?

the old tool at https://github.com/quarkiverse/quarkus-file-vault/tree/main/vault-utils printed out:

######################################################################################################
Please add the following parameters on your application.properties file, and replace the <name> value!
The <name> will be used in the consumer to refer to this provider.

quarkus.file.vault.provider.<name>.encryption-key=the_encryption_key
quarkus.file.vault.provider.<name>.secret=4VLLc9bk+WMnQMR3ezJcpw==
######################################################################################################

this script seem to just be about generating the encrypted value for a key/property?

so if i grok it right ultimately what we would do is do allow something like:

quarkus config encrypt --secret blah.file quarkus.datasource.password=blablah and it would go and actually update the properties file for you ?

now it just prints the value - which is nice; but in quarkus we should be able to do that for the user, right?

[maxandersen]

is there some hints in users config on what algorithm they might be using for this so default value could be figured out from there ?

not a blocker for this pr - just trying to think what could be best in future.

[radcortez]

Yes, the secret handler expression. For instance, to set a secret value and a way to decrypt it you need something like:

quarkus.datasource.password=${aes-gcm-nopadding::SECRET}
smallrye.config.secret-handler.aes-gcm-nopadding.encryption-key=key

But I'm probably going to change that to be more generic, like:

quarkus.datasource.password=${dec::SECRET}
smallrye.config.secret-handler.dec.alg=AES
...

The only problem is that you can have multiple handlers. We can discover all the available handlers and the user can select which one to use. We can also retrieve the encryption key if available (not likely, because I would expect that the encryption key will not be stored in application.properties or any other source available to the CLI, but we can do it as a best effort).

[radcortez]

now it just prints the value - which is nice; but in quarkus we should be able to do that for the user, right?

Yes, it would be possible if we know the configuration property name. With the current Secret Handler approach and encryption, it is possible for the user to encrypt any key,

Maybe an alternative way is to just pass the configuration property name and we can pick the value, encrypt it and update the configuration file. Note that if the user has higher ordinal sources or sources that we cannot update, the user will need to do it manually.

[maxandersen]

okey. then my suggestion is that instead of creating a high-level "encryptor" we make a top level "config" with an "encrypt" sub command. as we can imagine adding other helpful config commands to the cli.

wdyt?

@ebullient @iocanel

[radcortez]

Sounds good to me :)

[ebullient]

okey. then my suggestion is that instead of creating a high-level "encryptor" we make a top level "config" with an "encrypt" sub command. as we can imagine adding other helpful config commands to the cli.

wdyt?

@ebullient @iocanel

sounds reasonable ...

you're thinking a la git config ... ?

[maxandersen]

@ebullient yeah - though we actually have two kind of configs... the config of the app and the config of the cli...
for quarkus config i'm thinking mainly the app config part.

[radcortez]

I've updated the PR (and the description) with some of the ideas. If we are happy with the direction, then I can move forward and complete the PR.

[sberyozkin]

Thanks @radcortez for making the key optional - as various algorithms may require different length, etc, should be easier for users if they don't already have the one.
LGTM, thanks

[github-actions]

🙈 The PR is closed and the preview is expired.

[gsmet]

Let's get this in and gather feedback!

[maxandersen]

wanted to use this today and noticed it isn't in...anything holding it back @radcortez ?

[radcortez]

Nothing is holding it back. Let me rebase this with the latest.