A Kubernetes controller to watch ingresses and create liveness alerts for your apps/microservices in UptimeRobot, StatusCake, Pingdom, etc. – [✩Star] if you're using it!
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.
// +optional
RequestHeadersEnvVar string `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 calledrequestHeadersEnvVarto thePingdomConfig:This field should behave in the same way as the normal
requestHeadersfield, 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 :)