Add support for custom config variables

[mohabusama]

Could be useful in supplying special variables that are accessible to all check commands. One use case is authorization tokens that can be used in http wrapper to initiate authorized requests.

Suggestion:

Store in a dict in config

New command, Eg: secrets() or vars() etc ...

Example usage

vars('my_service_token')

[Jan-M]

The issue here we always face is how to prevent someone from returning the
secret values.

IMHO we need to check if one can use some kind bind() operation that is not
assignable to the result.

On Thursday, 8 September 2016, Mohab Usama notifications@github.com wrote:

Could be useful in supplying special variables that are accessible to all
check commands. One use case is authorization tokens that can be used in
http wrapper to initiate authorized requests.

Suggestion:

Store in a dict in config

New command secrets() or vars() etc ...

Example usage

vars('my_service_token')

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#132, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABYGQ7bEtvJH9ECmNEK7HtIo7LoK7DBgks5qoDbOgaJpZM4J4L7j
.

Jan Mußler
Senior Platform Engineer | +49 176 1275 8727 | Zalando SE

[mohabusama]

Well, we can perform "deep return value inspection" and prevent returning "custom configs", but even if it is done it won't be sufficient. For instance we won't be able to prevent (hard to prevent) http('http://my-service?secret_token=' + vars('token')) or custom form of encoding.

I think the core problem is revolving around permissions rather than return values visibility. Which is more or less related to the entire chain (teams->checks->alerts->entities->workers(appliances) ...).

Protecting secrets aside, having custom variables populated in config could as well help DRY in writing checks.