You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Some of our Pingdom Uptime checks use an api token in the request header for authentication. It is possible to add request headers in the EndpointMonitor (see here). However, at the moment these headers are stored in plain text. It would be nice to read these headers from the environment/a secret and not store them in plain text.
Describe the solution you'd like
Reading such information from the environment is already implemented with the postDataEnvVar ( see here). Thus, I would propose to follow the same approach and add a new field called requestHeadersEnvVar to the PingdomConfig:
// Custom request headers that should be read from an environment variable as it possibly contains sensitive data.// An example would be an API token.// +optionalRequestHeadersEnvVarstring`json:"requestHeadersEnvVar,omitempty"`
This field should behave in the same way as the normal requestHeaders field, i.e., it needs to be valid json.
Describe alternatives you've considered
We could also let the operator read the data from a secret directly. This is more complex because:
the controller needs to know when to read information from a secret. This could be achieved using additional fields in the CRD (e.g. something like secretRef) or with some custom syntax.
Is your feature request related to a problem? Please describe.
Some of our Pingdom Uptime checks use an api token in the request header for authentication. It is possible to add request headers in the EndpointMonitor (see here). However, at the moment these headers are stored in plain text. It would be nice to read these headers from the environment/a secret and not store them in plain text.
Describe the solution you'd like
Reading such information from the environment is already implemented with the
postDataEnvVar
( see here). Thus, I would propose to follow the same approach and add a new field calledrequestHeadersEnvVar
to thePingdomConfig
:This field should behave in the same way as the normal
requestHeaders
field, i.e., it needs to be valid json.Describe alternatives you've considered
We could also let the operator read the data from a secret directly. This is more complex because:
secretRef
) or with some custom syntax.Additional context
I can provide a PR to implement this :)
The text was updated successfully, but these errors were encountered: