Kubeform-provider-google-tags-crds Helm Chart

Kubeform-provider-google-tags-crds
Analyzed version: 2021.10.29

By AppsCode Inc.

Kubeform Provider Google Tags Custom Resource Definitions

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.

Latest version: 15.5.3
View GitHub

How to Install the Kubeform-provider-google-tags-crds Helm Chart

Add Chart Repository to Helm

helm repo add appscode https://charts.appscode.com/stable/

Install Chart

helm install my-kubeform-provider-google-tags-crds appscode/kubeform-provider-google-tags-crds --version 2021.10.29

Does the Kubeform-provider-google-tags-crds Chart Follow Industry Best Practices?

The chart meets the best practices recommended by the industry.

The chart failed to meet 0 of the best practices recommended by the industry.

The chart meets the best practices recommended by the industry. Find the full list of best practices here.

✅️ Prevent Ingress security vulnerability (CVE-2021-25742)

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).

To learn more about the best practice click here

✅️ 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.

To learn more about the best practice click here

✅️ Ensure each container has a configured memory request

Memory requests allow you to use memory resources efficiently and allow you to allocate a guaranteed minimum of computing resources for the pods running in your cluster.

To learn more about the best practice click here

✅️ Ensure each container has a configured CPU request

CPU requests enable you to use CPU resources efficiently and to allocate a guaranteed minimum of computing resources for the pods running in your cluster.

To learn more about the best practice click here

✅️ Ensure each container has a configured memory limit

Memory limits enable you to use memory resources efficiently. By setting memory limits, you restrict the maximum amount of memory available to the pods running in your cluster.

To learn more about the best practice click here

✅️ Ensure each container has a configured CPU limit

CPU limits enable you to use CPU resources efficiently by restricting the maximum amount of CPU available to the pods running in your cluster.

To learn more about the best practice click here

✅️ 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.

To learn more about the best practice click here

✅️ Ensure CronJob scheduler is valid

You should always confirm that the cron schedule expression is valid or your jobs won't be executed.

To learn more about the best practice click here

✅️ Ensure workload has valid label values

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.

To learn more about the best practice click here

✅️ 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.

To learn more about the best practice click here

✅️ Ensure each container has a configured liveness probe

Liveness probes allow Kubernetes to determine when a pod should be replaced. They are fundamental in configuring a resilient cluster architecture.

To learn more about the best practice click here

✅️ Ensure each container has a configured readiness probe

Readiness probes allow Kubernetes to determine when a pod is ready to accept traffic. This ensures that client requests will not be routed to pods that are unable to process them.

To learn more about the best practice click here

✅️ Ensure HPA has minimum replicas configured

When auto-scaling resource utilization is triggered with HPA (HorizontalPodAutoscaler), a range of acceptable values must be set to prevent unintended scaling down scenarios.

To learn more about the best practice click here

✅️ Ensure HPA has maximum replicas configured

When auto-scaling resource utilization is triggered by HPA (HorizontalPodAutoscaler), a range of acceptable values must be set to prevent unintended scaling-up scenarios.

To learn more about the best practice click here

✅️ Ensure each container has a configured liveness probe

Liveness probes allow Kubernetes to determine when a pod should be replaced. They are fundamental in configuring a resilient cluster architecture.

To learn more about the best practice click here

✅️ Ensure each container has a configured readiness probe

Readiness probes allow Kubernetes to determine when a pod is ready to accept traffic. This ensures that client requests will not be routed to pods that are unable to process them.

To learn more about the best practice click here

✅️ Ensure HPA has minimum replicas configured

When auto-scaling resource utilization is triggered with HPA (HorizontalPodAutoscaler), a range of acceptable values must be set to prevent unintended scaling down scenarios.

To learn more about the best practice click here

✅️ Ensure HPA has maximum replicas configured

When auto-scaling resource utilization is triggered by HPA (HorizontalPodAutoscaler), a range of acceptable values must be set to prevent unintended scaling-up scenarios.

To learn more about the best practice click here

✅️ 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.

To learn more about the best practice click here

✅️ Ensure CronJob has a configured deadline

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.

To learn more about the best practice click here

✅️ Prevent deprecated APIs in Kubernetes v1.16

The v1.16 release stopped serving some API versions for different resource types. When a user deploys a resource with a deprecated API version, the Kubernetes engine rejects it.

To learn more about the best practice click here

✅️ Prevent deprecated APIs in Kubernetes v1.17

The v1.17 release stopped serving some API versions for different resource types. When a user deploys a resource with a deprecated API version, the Kubernetes engine rejects it.

To learn more about the best practice click here

✅️ Prevent containers from having root access capabilities

Processes running in privileged containers have access to host-level resources such as the file system. These containers are much more secure when their access is limited to the pod level.

To learn more about the best practice click here

✅️ 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.

To learn more about the best practice click here

✅️ Prevent EndpointSlice validation from enabling host network hijack (CVE-2021-25737)

A vulnerability has been found in Kubernetes kube-apiserver in which an authorized user could redirect pod traffic to private networks on a node (NVD severity of this issue: Low).

To learn more about the best practice click here

This is some text inside of a div block.
This is some text inside of a div block.

Reveal misconfigurations within minutes

3 Quick Steps to Get Started