[Feature] Handling credentials about configuration-as-code-plugin HOT 12 CLOSED

I believe this issue can be closed. We've got a working prototype for Vault, Docker secrets and the EnvironmentSecrets using an extension point.

We could elaborate further. But thtat would be a new issue

from configuration-as-code-plugin.

From slack:

but in a configuration-as-code environment, I would anyway expect jenkins credentials to rely on some external secret store
like Vault or Docker Secret
and c-as-c to only configure credentials plugin accordingly
AFAIK the extension points already exists, I think there's a CloudBees plugin using it (can check)

so the plan is to verify it with Vault using Jenkins Vault Plugin

from configuration-as-code-plugin.

I see two topics to be covered here:

1. configure jenkins credentials plugin's store with some initial secrets
2. inject secret as configuration value (for sample : smtp server password)

For the former, I think this is a larger topic than CasC, and would better be implemented with a dedicated CredentialsProvider plugin to connect to Vault or comparable secret store. Typically, I'd like to get jenkins enhanced with adequate plugin, and have CasC configure this plugin with Vault token.

The later is only supported at time writing with environment variable replacement, which is the lowest secure solution we can imaging (secret will be dumped on jenkins admin UI !). But we can use this exact same String replacement mechanism with adequate SPI in CasC so a extension plugin can provide support for getting those secrets from Vault store, and do variable substitution based on Vault keys.

from configuration-as-code-plugin.

let's try with Vault

from configuration-as-code-plugin.

If im reading this issue correctly there are two issues we need to fix:

1. A mechanism/convention needs to be introduced which allows us to variable substitute fields in the conifg.yml file which are evaluated when the file is parsed by c-as-c.

2. This mechanism needs to be extendable so that a plugin that provides credentials also can provide credentials for this part of c-as-c.

I think i mostly understand this, but won't we have a chicken and egg problem? Wouldn't the plugin that provides credentials need to be configured before c-as-c?

from configuration-as-code-plugin.

variable substitution is already supported based on environment variables. It could be enhanced to support a "secret source" with Env as default implementation.

an alternative source can be docker secret / kubernetes secret / a vault connector. All those should be hosted by dedicated "extension" plugins. Such a plugin has to be pre-installed (like configuration-as-code-plugin !) so it can setup the master. Consider something like a jenkins-casc-for-kubernetes distribution.

This only targets plugins which rely on Secret. credentials-plugin support should be implemented as a CredentialsProvider implementation plugin

from configuration-as-code-plugin.

Unless I'm missing something, https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/src/main/java/org/jenkinsci/plugins/casc/EnvSecretSource.java looks like a terrible idea, given they're exposed e.g. on /systemInfo in plain.

While there appear to be alternatives, it's probably a good idea not to make it too easy for users to shoot themselves in the foot.

from configuration-as-code-plugin.

@daniel-beck I don't think it's our role to educate users on the risk to rely on env variables to pass secrets as configuration parameters. This has been an issue with many softwares, including springframework as a very popular one. On the other hand this is pretty useful for developers to be able to override configuration this way with just a system property or -e option on docker command line.
We offer an alternative for those who want to follow basic security recommendations, we can't just force them to do so.

from configuration-as-code-plugin.

@ndeloof On the other hand, there are many examples in this repo that show adding credentials via environment variables. It may not be your job to educate users about security practices, but it's not great to mislead your users either, especially those who are not versed in best security practices.

from configuration-as-code-plugin.

@dead10ck we are working on generalizing the string replacement mechanism to offer string interpolation, not just secret management, which will make the env variable support a first class citizen. But if you have identified some security bad practices in sample we need to fix them, or at least provide a warning; please provide links

from configuration-as-code-plugin.

Well, environment variables are not really a great security practice. It might still be common in some applications, but that recognition is why tools like Vault are popping up. This article has some information about it.

from configuration-as-code-plugin.

Yes indeed, environment variable is only supported for not-so-sensible data and for test/demo purpose, we strongly recommend to use a better secret source. Should maybe be more explicit in the docs

from configuration-as-code-plugin.