Kubernetes

Kubernetes 1.19

Kubernetes 1.19

The Kubernetes 1.19 reached end of service life on Oct 28, 2021 — Kubernetes no longer ships security patches or fixes for it. Our third-party support keeps it safe to run: 24/7 engineers manage issues, remediate vulnerabilities, and help you maintain compliance.

End of Service LifeEOSL Date: Oct 28, 2021
Issue Management

24/7 engineers own your Kubernetes 1.19 incidents end to end.

Vulnerability Remediation

Mitigation and patch-around guidance when the vendor no longer ships fixes.

Compliance Maintenance

Controls evidence and documentation that keep auditors satisfied.

Specifications

product
kubernetes
release
1.19
product Label
Kubernetes
release Label
1.19
codename
lts
latest Version
1.19.16
release Date
2020-08-26
maintained
source Url
https://endoflife.date/kubernetes

Lifecycle Dates

End of Service Life
Oct 28, 2021
Last OEM Support
Aug 28, 2021

Get Third Party Support

Your quote will be sent to this address.

By submitting this form, you agree to our Privacy Policy.

OEM vs. 3rd Party Support

See how third-party support compares to the vendor contract for Kubernetes 1.19 — monitoring, break/fix, vulnerability work, operations and compliance, before and after EOSL.

FeatureOEM Support3rd Party Support
Post-EOSL Support
Break/Fix Support
Until EOSL
24/7 Monitoring
Vulnerability Scanning & Remediation
Managed Operations
Procedure & Configuration Review
Compliance & Audit Documentation
Limited
Discounted Migration to Other Platforms

Why Choose 3rd Party Support for Kubernetes 1.19?

Vulnerability Remediation

Scanning, mitigation and patch-around guidance for Kubernetes 1.19 when the vendor no longer ships fixes.

Compliance Maintenance

Procedure review, controls evidence and the documentation auditors ask for — maintained continuously, not scrambled at audit time.

24/7 Expert Support

Engineers who know this release monitor, manage and fix issues around the clock — break/fix to managed operations.

Kubernetes 1.19 Support: Frequently Asked Questions

Is the Kubernetes 1.19 still supported?

Kubernetes ended support for the Kubernetes 1.19 on Oct 28, 2021 — no more patches or fixes from the vendor. Third-party support keeps it covered: our engineers manage issues, remediate vulnerabilities, and help you maintain compliance for as long as you run it.

When is the Kubernetes 1.19 end of service life (EOSL) date?

Kubernetes lists the end of service life for the Kubernetes 1.19 as Oct 28, 2021.

Can I keep using the Kubernetes 1.19 after its EOSL date?

Yes. EOSL means Kubernetes stops issuing patches and support — the software itself keeps running. Third-party support covers it from there: issue management, security vulnerability remediation, and the compliance documentation auditors ask for, for as long as you choose to run it.

How much does third-party support for the Kubernetes 1.19 cost?

Typically 40-70% below the OEM maintenance renewal price. Exact pricing depends on quantity, service level and location — request a quote and we respond within 24 hours.

Known Vulnerabilities Affecting Kubernetes 1.19

24 published CVEs affect the Kubernetes 1.19, including 7 rated critical or high severity. Kubernetes no longer ships security patches for this release — our engineers provide mitigation guidance, workarounds and hardening support.

CVESeverityCVSSPublishedSummary
CVE-2016-1906CRITICAL9.8Feb 3, 2016Openshift allows remote attackers to gain privileges by updating a build configuration that was created with an allowed type to a type that is not allowed.
CVE-2023-3955HIGH8.8Oct 31, 2023A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.
CVE-2023-3676HIGH8.8Oct 31, 2023A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they include Windows nodes.
CVE-2021-25741HIGH8.8Sep 20, 2021A security issue was discovered in Kubernetes where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.
CVE-2016-1905HIGH7.7Feb 3, 2016The API server in Kubernetes does not properly check admission control, which allows remote authenticated users to access additional resources via a crafted patched object.
CVE-2016-7075HIGH7.5Sep 10, 2018It was found that Kubernetes as used by Openshift Enterprise 3 did not correctly validate X.509 client intermediate certificate host name fields. An attacker could use this flaw to bypass authentication requirements by using a specially crafted X.509 certificate.
CVE-2023-5528HIGH7.2Nov 14, 2023A security issue was discovered in Kubernetes where a user that can create pods and persistent volumes on Windows nodes may be able to escalate to admin privileges on those nodes. Kubernetes clusters are only affected if they are using an in-tree storage plugin for Windows nodes.
CVE-2022-3294MEDIUM6.6Mar 1, 2023Users may have access to secure endpoints in the control plane network. Kubernetes clusters are only affected if an untrusted user can modify Node objects and send proxy requests to them. Kubernetes supports node proxying, which allows clients of kube-apiserver to access endpoints of a Kubelet to establish connections to Pods, retrieve container logs, and more. While Kubernetes already validates the proxying address for Nodes, a bug in kube-apiserver made it possible to bypass this validation. B
CVE-2023-2728MEDIUM6.5Jul 3, 2023Users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the `kubernetes.io/enforce-mountable-secrets` annotation are used together with ephemeral containers.
CVE-2023-2727MEDIUM6.5Jul 3, 2023Users may be able to launch containers using images that are restricted by ImagePolicyWebhook when using ephemeral containers. Kubernetes clusters are only affected if the ImagePolicyWebhook admission plugin is used together with ephemeral containers.
CVE-2022-3162MEDIUM6.5Mar 1, 2023Users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group without authorization. Clusters are impacted by this vulnerability if all of the following are true: 1. There are 2+ CustomResourceDefinitions sharing the same API group 2. Users have cluster-wide list or watch authorization on one of those custom resources. 3. The same users are not authorized to read another custom resource in the same API gr
CVE-2021-25735MEDIUM6.5Sep 6, 2021A security issue was discovered in kube-apiserver that could allow node updates to bypass a Validating Admission Webhook. Clusters are only affected by this vulnerability if they run a Validating Admission Webhook for Nodes that denies admission based at least partially on the old state of the Node object. Validating Admission Webhook does not observe some previous fields.
CVE-2020-8554MEDIUM6.3Jan 21, 2021Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.externalIPs field, to intercept traffic to that IP address. Additionally, an attacker who is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
CVE-2021-25736MEDIUM5.8Oct 30, 2023Kube-proxy on Windows can unintentionally forward traffic to local processes listening on the same port (“spec.ports[*].port”) as a LoadBalancer Service when the LoadBalancer controller does not set the “status.loadBalancer.ingress[].ip” field. Clusters where the LoadBalancer controller sets the “status.loadBalancer.ingress[].ip” field are unaffected.
CVE-2020-8566MEDIUM4.7Dec 7, 2020In Kubernetes clusters using Ceph RBD as a storage provisioner, with logging level of at least 4, Ceph RBD admin secrets can be written to logs. This occurs in kube-controller-manager's logs during provisioning of Ceph RBD persistent claims. This affects < v1.19.3, < v1.18.10, < v1.17.13.
CVE-2020-8565MEDIUM4.7Dec 7, 2020In Kubernetes, if the logging level is set to at least 9, authorization and bearer tokens will be written to log files. This can occur both in API server logs and client tool output like kubectl. This affects <= v1.19.3, <= v1.18.10, <= v1.17.13, < v1.20.0-alpha2.
CVE-2020-8564MEDIUM4.7Dec 7, 2020In Kubernetes clusters using a logging level of at least 4, processing a malformed docker config file will result in the contents of the docker config file being leaked, which can include pull secrets or other registry credentials. This affects < v1.19.3, < v1.18.10, < v1.17.13.
CVE-2020-8563MEDIUM4.7Dec 7, 2020In Kubernetes clusters using VSphere as a cloud provider, with a logging level set to 4 or above, VSphere cloud credentials will be leaked in the cloud controller manager's log. This affects < v1.19.3.
CVE-2023-2431LOW3.4Jun 16, 2023A security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. Pods that use localhost type for seccomp profile but specify an empty profile field, are affected by this issue. In this scenario, this vulnerability allows the pod to run in unconfined (seccomp disabled) mode. This bug affects Kubelet.
CVE-2021-25740LOW3.1Sep 20, 2021A security issue was discovered with Kubernetes that could enable users to send network traffic to locations they would otherwise not have access to via a confused deputy attack.

Showing the 20 most severe of 24 known CVEs.

Get Third Party Support

Related Kubernetes Products

All Kubernetes products →
Kubernetes 1.19
Save 40-70% vs OEM
Get Third Party Support