Feature to disable plugin output to build log

[ghost]

There is a security/usage issue with this plugin in TC. Plugin allows you to configure only one connection to Vault, so it means you can run only 1 AppRole, but I think I am not the only one, who has use case where multiple different teams can store secrets in Vault and use with TC, but they do not want that anyone else could access it. So after making AppRole, you add all the policies which could be used with that AppRole and the safeguard would be a secret path, without exact path you can't get the secret values. Currently plugin gives the output to buildlog, so partialy anyone can look at build log and see this information.

[12:38:00]
The build is removed from the queue to be prepared for the start
[12:38:00]
Starting the build on the agent build-agent-name
[12:38:01]
HashiCorp Vault
[12:38:01]
[HashiCorp Vault] HashiCorp Vault token successfully fetched
[12:38:01]
[HashiCorp Vault] 1 Vault reference to resolve: [vault:secret/path/to/some/very/secret!/value]
[12:38:01]
Clearing temporary directory: /mnt/temp/buildTmp
[12:38:01]
Publishing internal artifacts

It doesn't help if you make hidden or password in parameters, because it's exposed in a code.

Would be great to have opportunity to "silence" this.

[zetta]

Why do you need a path to be secret? does your path contains a secret itself?

[ghost]

@zetta do you even know how Vault works?

TC can only accept 1 AppRole in the settings. If a TC instance is used by different teams, so everyone has access to AppRole, which has access to defined policies and eventually - secrets. The only way to protect yourself is to hide a secret path, so users could not find it and use it in their code.

Real example if you still didn't understood: I have AWS root credentials specified at secret/aws/root!/value I assign it to ENV var and use it in my jobs, that's AWESOME!

But here comes person A who reads my secret path and assigns it to it's own ENV var and uses MY SECRET in his jobs! without a path, even having access to APpRole he wouldn't be able to read it.

[zetta]

@zetta do you even know how Vault works?

I would like to help you with some ideas but seems like you are more experienced than me, let me go back and read more documentation.

[VladRassokhin]

I'd say that proper fix would be not hiding path but supporting several Vault project features. There's already PR for that, though I had no time to review it.

Also feature could be overridden in another project. So for now if you need some isolation - setup different project with different features.

[VladRassokhin]

Multiple namespaces are now supported, thanks to #12, so I'd prefer to close this issue

[ghost]

For me it seems a bit weird to create AppRole for each project, when you have TC serving whole enterprise and 30-40 different projects. I'd still prefer to silence the output, because having 1 AppRole it's easier to maintain permissions when they are in one place.

Also having 1 AppRole allows to automate Vault part, by creating all policies and adding them to 1 particular AppRole, you don't need to go to TC and click & type the role-id/secret-id for each project.

[VladRassokhin]

"Weird" but secure. If you think that developers of one project may do something with another then all credentials and AppRoles must be separated.

[ghost]

Not really, you need to know exact path to the secret, AppRole just gives you the policies, which describes the accesses. Without a path, you cannot do anything. Secret paths are known only for secrets owners, because you can create secret paths with random strings/guid, etc secrets/das32312d/daswd123213/3213dlkaflkaslfasfa/aws_creds!/value and you are giving away this in console output. That's not secure either, because if paths contains relevant information, you can give away sensitive info, like secrets/clients/NSA/russia/secrets?/value :)