Removing liveness probe to prevent killing prometheus pod during WAL
replay.
This should be reverted around kubernetes 1.21 release. At that point
startupProbe should be added.
When the Thanos spec doesn't configure object storage, there's no need to
configure the Thanos sidecar for block uploads and mount the
Prometheus data volume.
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
* refactor: decouple pod labels from selector labels
prometheus pods can not be rolled out without downtime when label's are changed
Fixes#3120
* chore: run go fmt
* fix unit tests
This allows nested PersistentVolumeClaim fields to be validated and
maintain metadata information such as labels and annotations.
Signed-off-by: Paul Gier <pgier@redhat.com>
Recent updates to the CRD generation caused pod labels and annotations
to be lost due to no longer recursing into the ObjectMeta type to gather
all the fields. This change allows labels and annotations to be preserved in
the custom Promtheus, Alertmanager, and ThanosRuler custom resources.
Fixes#3041
Currently when passing `--config-reloader-(cpu|memory)` values those are
used only for limits. This PR sets the same values for requests.
I wasn't sure if the options for the requests should have been passed
with separate options but I thought this was a good compromise in the
meantime.
The initial question was brought up in https://github.com/coreos/kube-prometheus/issues/376
When the operator transfers all labels and annotations from the source
prometheus object to the generated statefulset this also kubectl managed
annotations.
These annotations will cause the generated statefulset to be pruned when
the source prometheus is applied with kubectl apply --prune.
Cleanup of the statefulset is managed by the garbage collection via
owner references of the prometheus object (which can be pruned).
To fix this do not transfer any kubectl.kubernetes.io/ annotations to
the generated statefulset.
Closes gh-2642
Signed-off-by: Julian Taylor <juliantaylor108@gmail.com>
When using prometheus with listenLocal=true the wget probe in the pod
failed because the created download file prenvents further successfull
wget runs.
Using /dev/null for the wget output file fixes that.
Fixes#2921
To configure a bearer token users could only specify a file path in the
service monitor, pointing to a bearer token file in the Prometheus
container. This enables hostile users, being able to configure a service
monitor and controlling the scrape target, to retrieve arbitrary files
in the Prometheus container.
In cases where users can not be trusted, this patch adds an option to
disallow the above file path specification and replaces it by a secret
reference. This secret has to be in the same namespace as the service
monitor, shrinking the attack vector.
pkg/prometheus: Add option to deny file system access through service monitors
ArbitraryFSAccessThroughSMsConfig enables users to configure, whether
a service monitor selected by the Prometheus instance is allowed to use
arbitrary files on the file system of the Prometheus container. This is
the case when e.g. a service monitor specifies a BearerTokenFile in an
endpoint. A malicious user could create a service monitor
selecting arbitrary secret files in the Prometheus container. Those
secrets would then be send with a scrape request by Prometheus to a
malicious target. Denying the above would prevent the attack, users can
instead use the BearerTokenSecret field.
test/basic-auth-test-app: Add mTLS endpoint
pkg/prometheus: Enable users to configure tls from secret
pkg/prometheus/operator: Validate TLS configs before retrieving assets
Before retrieving TLS assets from Kubernetes secrets for a given service
monitor, make sure the user did not specify both file and secret
reference, e.g. both `CAFile` and `CASecret`.
test: Rename basic-auth-test-app to instrumented-sample-app
Given that the basic-auth-test-app not only supports basic auth, but
also bearer token as well as tls authentication, this patch renames the
app to a more generic name.
test/e2e/prometheus_test: Test ArbitraryFSAccessThroughSM option for tls
The Prometheus custom resource has the option to disable arbitrary
filesystem access configured through service monitors. This commit adds
an end-to-end test for this option in combination with the TLS
configuration via files or secret references in service monitors.
pkg/prometheus/operator: Move check for arbitrary fs access into func
Use k8sutil.MergePatchContainers() to patch the "stock" prometheus
stateful set created by the CRD with any additional containers
requested. Additional containers include generated containers like
thanos and user added ones defined by .spec.containers
add a very basic test case asserting that additional container specs in
the prometheus crd are added to the statefulset that reflects the
current behavior
Users have reported high CPU usage of the Prometheus Operator when
adding an annotation to a Prometheus object. The Operator would update
the respective StatefulSet in an infinite loop.
Whether a given StatefulSet needs updating is determined by the hash of
the inputs needed to generate the StatefulSet, which is calculated and
then attached to the StatefulSet as an annotation. On subsequent
reconciliations this hash is compared to the hash of the new inputs.
The function to build the StatefulSet definition is passed the
Prometheus object. This is done by value, not by reference. This does
not enforce a deep copy but merely a shallow copy. In the build function
the new StatefulSet would inherit the annotation map of the Prometheus
object. Next the input hash would be added to this map, resulting in
both the Statefulset having the hash annotation, as intended, as well as
the Prometheus object (same map, shared as a reference).
On subsequent reconciliations the same Prometheus object is used to
calculate the input hash, this time accidentally containing the has
annotation from the previous run. Even though the actual inputs never
changed, this results in a new hash, thereby updating the StatefulSet,
...
The solution is to deep copy the Prometheus object before using it in
the StatefulSet build function, thereby never mutating the annotations
of the Prometheus object. Same measure is taken for the Alertmanager
StatefulSet build function.
