What's New in Kubernetes 1.8

The newly released Kubernetes 1.8 is the third release this year, and shows great progress and maturity of the Kubernetes project. I’m happy that the community continues to make progress in several security-related areas that have been under development or in beta for a while, and are now officially released.

Here are some of the new Kubernetes 1.8 capabilities with examples of how they can be used:

RBAC Authorization

RBAC authorization is now promoted to the stable branch, allowing Kubernetes administrator to define access control policies for Kubernetes API.

To enable RBAC, start the apiserver with - - authorization-mode=RBAC

With RBAC, you can create Role objects that define user access to Kubernetes resources.
For example, the following Role “pod-reader” defines permissions to read all pods within the default namespace:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
   namespace: default
   name: pod-reader
rules:
-  apiGroups: [""] # "" indicates the core API group
   resources: ["pods"]
   verbs: ["get", "watch", "list"]

You can then create a RoleBinding object to assign user and group access to a Role.
For example, the following RoleBinding assigns the “pod-reader” Role to user “jane”:

You can read more about the RBAC authorization in the Kubernetes Documentation.

Beta Support for Outbound Network Policies

A network policy is a specification of how pods are allowed to communicate with each other and with other network endpoints.

By default, pods are not isolated from the network - they accept traffic from any source and can communicate with any destination.

You can apply network rules on a pod by creating a NetworkPolicy resource. For example, the following NetworkPolicy defines limitation for incoming and outgoing network communication on pod with label “role:db”:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
   name: test-network-policy
   namespace: default
spec:
   podSelector:
     matchLabels:
       role: db
   policyTypes:
   - Ingress
   - Egress
   ingress:
   - from:
     - ipBlock:
         cidr: 172.17.0.0/16
         except:
         - 172.17.1.0/24
   - namespaceSelector:
         matchLabels:
           project: myproject
   - podSelector:
         matchLabels:
           role: frontend
   ports:
   - protocol: TCP
     port: 6379
egress:
   - to:
     - ipBlock:
         cidr: 10.0.0.0/24
   ports:
   - protocol: TCP
     port: 5978

Beta support for filtering outbound network traffic through NetworkPolicy is a new addition in Kubernetes 1.8. It complements the inbound network traffic filtering that was introduced in previous version.

Note that Kubernetes defines the specification for NetworkPolicy resources. You need to make sure that you have a network plugin that can implement these policies.

You can read more about network policies here.

Beta Support for Advanced Auditing

Kubernetes 1.7 expanded auditing with experimental functionality such as event filtering and a webhook for integration with external systems. Kubernetes 1.8 upgrades the advanced audit feature to beta. This feature introduces formatted audit logs and webhook support to sent events to external services.

The following example shows how to create an audit policy:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
rules:
 # Log pod changes at Request level
 - level: Request
   resources:
   - group: ""
     # Resource "pods" no longer matches requests to any subresource of pods,
     # This behavior is consistent with the RBAC policy.
     resources: ["pods"]
 # Log "pods/log", "pods/status" at Metadata level
 - level: Metadata
   resources:
   - group: ""
     resources: ["pods/log", "pods/status"]

 # A catch-all rule to log all other requests at the Metadata level.
 # For this rule we use "omitStages" to omit events at "ReqeustReceived" stage.
 # Events in this stage will not be sent to backend.
 - level: Metadata
   omitStages:
     - "RequestReceived"

You can read more about advanced auditing here.

Beta Support for TLS Certificate Rotation

The kubelet uses certificates for authenticating to the Kubernetes API. By default, these certificates are issued with one year expiration so that they do not need to be renewed too frequently.
Kubernetes 1.8 contains kubelet certificate rotation, a beta feature that will automatically generate a new key and request a new certificate from the Kubernetes API as the current certificate approaches expiration. Once the new certificate is available, it will be used for authenticating connections to the Kubernetes API.

To enable certificate rotation, you should pass the argument - - rotate-certificates to the kublete process. This will trigger kublet to automatically request a new certificate as the expiration of the existing certificate it is using is approaching.

Since certificate rotation is a beta feature, it should be enabled with
- - feature-gates=RotateKubeletClientCertificate=true.

In addition, the kube-controller-manager process accepts an argument - - experimental-cluster-signing-duration that controls how long certificates will be issued for.

You can read more about the new TLS certificate rotation here.

Beta Support for ContainerD

A beta release of cri-containerd allows Kubernetes to communicate with containerd instead of Docker Daemon.

The cri-containerd is a Kubernetes incubation project that creates a new shim between Kublet and ContainerD, based on the CRI interface.

Diagram credit: Docker Blog

See this blog for more information.

Spotlight on Workload Support

Kubernetes 1.8 promotes the core Workload APIs to beta.

The Workloads APIs provide a stable foundation for migrating existing workloads to Kubernetes as well as developing cloud native applications that target Kubernetes natively.

Some of the interesting APIs that are now available in beta are Cron Jobs and Apache Spark.

What does it mean for Aqua Security?

At Aqua Security we continue to focus on securing containerized applications across technology stacks (clouds, OSs, orchestrators, and container engines). Our approach is to add our security controls on top of the existing platforms’ security controls, in order to provide more robust security with consistent, scalable and easy-to-manage experience across enterprise environments.

Aqua Security customers can expect a version that incorporates and leverages Kubernetes 1.8 soon.