Kubernetes 1.19 Brings Fully Mature Ingress, Secure Computing Mode

Although the release of Kubernetes’ most recent version was a bit delayed, the Kubernetes release team just introduced Kubernetes version 1.19, with several updates that enhance the production readiness of Kubernetes. These improvements include the general availability of Ingress and seccomp features, security improvements, such as TLS 1.3 support, and other enhancements for functionality.
While the Kubernetes team has historically released four updates per year, it will release only three versions this year, because of pandemic conditions. Version 1.19 will likely be the final update of this calendar year.
GA Improvements: Ingress and seccomp

Ingress was initially introduced as an API in beta in Kubernetes version 1.1. This feature enables users to control external access to services in a cluster to expose HTTP and HTTPS routes. It can also help manage load balancing, terminate SSL/TLS, and provide name-based virtual hosting capabilities. For the Ingress resource to function, an Ingress controller must be used. Kubernetes currently supports and maintains GCE and nginx controllers.
In version 1.19, Ingress graduates to general availability and was added to the networking v1 APIs. This update brings some key changes in v1 Ingress objects, including schema and validation changes.
seccomp (Security Computing Mode) also graduates to GA in Kubernetes version 1.19. seccomp is a security facility in the Linux kernel which restricts the amount of system calls applications can make. It was first introduced as a Kubernetes feature in version 1.3 but had some limitations. Previously, an annotation on a PodSecurityPolicy was required when applying seccomp profiles to pods.
In this release, seccomp introduces a new seccompProfile
field added to pod and container securityContext objects. To ensure Kubelet backwards compatibility, seccomp profiles will be enforced in a priority order:
- Container-specific field.
- Container-specific annotation.
- Pod-wide field.
- Pod-wide annotation.
The pod sandbox container is now also configured with a separate runtime/default
seccomp profile in this update.
Support for TLS 1.3
Following recommendations collected during last year’s security audit, Kubernetes version 1.19 adds support for new TLS 1.3 ciphers that can be used with the orchestrator.
Introducing Node debugs
Kubernetes 1.19 introduces the kubectl alpha debug
command, now available in alpha. This command will create and run a new pod in the host OS namespaces to troubleshoot nodes. Users can now inspect a running pod without having to restart it. In addition, users no longer have to enter the container itself to check systems or initiate operations such as debugging utilities or initial network requests from the pod network namespace. This enhancement eliminates the reliance on SSH for node maintenance and debugging
Warnings in Admission Webhooks
Admission webhooks can provide non-fatal warnings to API clients who make requests now in its beta version, introduced in Kubernetes 1.19. This enhancement makes it easier to recognize problematic API use.
Other Changes and Deprecations
In the spirit of inclusivity, Kubernetes 1.19 also includes changes in the terminology it uses to reflect more inclusive language, replacing whitelist with allowlist for example.
An additional change has been made to the Pod Topology Spread, which automatically weights topologies and applies better differentiation between nodes and zones to yield more balanced results across constraints. This feature was released in beta in version 1.18 to create simple definitions for complex pod layouts. Also, the Immutable Secrets and ConfigMaps feature, introduced in 1.18 as well, graduates to beta in 1.19.
Another notable update ensures that the default volume mount created for service account credentials has file permissions which will lead to increased security levels when running non-root containers. Version 1.19 now also supports JSON logging output from Kubernetes components by passing the flag `–log-format=json.
Hyberkube is now deprecated and will not be built by the Kubernetes project going forward. A few older beta API versions are also deprecated in version 1.19. They are slated to be removed in version 1.22, which may become a breaking release for many users.
The Future of Kubernetes
Those following the update cycles of Kubernetes closely might realize that support for sidecar containers was anticipated for release in 1.19 but has been postponed due to additional considerations by Kubernetes SIG-node. This development work will have a substantial impact on other projects, such as Istio.
Regardless, the team behind Kubernetes introduces several key enhancements in version 1.19 that continue to improve the security posture and broaden the functionality of Kubernetes. These updates are the result of a great community effort to implement these new features. For the complete list of changes, check out the official release notes.