Prometheus, a CNCF project, is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true.
This chart bootstraps a Prometheus deployment on a Kubernetes cluster using the Helm package manager.
A vulnerability has been discovered in Kuberenetes where users with limited access to a Kubernetes cluster, but with the ability to create an Ingress object based on the NGINX Ingress Controller, could elevate privilege and access full cluster secrets (NVD severity of this issue: High).
✅️ Ensure each container image has a pinned (tag) version
When an image tag is not descriptive (e.g. lacking the version tag like 1.19.8), every time that image is pulled, the version will be a different version and might break your code. Also, a non-descriptive image tag does not allow you to easily roll back (or forward) to different image versions. It is better to use concrete and meaningful tags such as version strings or an image SHA.
✅️ Prevent Ingress from forwarding all traffic to a single container
Misconfiguring the ingress host can unintended forward all traffic to a single pod instead of leveraging the load balancing capabilities. By verifying that ingress traffic is targeted by multiple pods, you will achieve higher application availability because you won't be dependent upon a single pod to serve all ingress traffic.
Labels are nothing more than custom key-value pairs that are attached to objects and are used to describe and manage different Kubernetes resources. If the labels do not follow Kubernetes label syntax requirements (see links below), they will not be applied properly.
✅️ Ensure deployment-like resource is using a valid restart policy
From the Kubernetes docs:"Only a .spec.template.spec.restartPolicy equal to Always is allowed, which is the default if not specified."Therefore, restartPolicy values like OnFailure or Never will be invalid and will not be applied as the user expect them to.
✅️ Prevent workload from using the default namespace
The namespace default is a saved namespace value in which Kubernetes is deploying all objects without an explicit namespace. Using explicit namespaces instead of the default value makes for clearer boundaries between sets of pods in a cluster. For example, namespaces that represent teams present a clear organization of cluster resources and make configuration overlaps less likely.
When the CronJob controller counts more than 100 missed schedules, the cron job is no longer scheduled. Missed CronJobs are considered failures.By default, the CronJob controller counts how many missed schedules happen for a cron job since status.lastScheduleTime until now. When startingDeadlineSeconds is set, the CronJob controller counts how many missed jobs occurred between the value of startingDeadlineSeconds until now.Setting a deadline can reduce the number of missed schedules needed to mark a CronJob as a failure while increasing the CronJob reliability.
✅️ Prevent CronJob from executing jobs concurrently
By default, the cron job allows concurrently running jobs but generally speaking, the behavior of your cron jobs will be more deterministic if you prevent them from running concurrently. Allowing concurrent cron jobs often requires locking mechanisms (to avoid race conditions) in addition to startup/cleanup handling.