Kubecon Europe 2020 - Day 1

Dernière mise à jour : 8 sept. 2021

For the first day of KubeCon CloudNativeCon Europe 2020 @Sokube (as a Silver Member of the CNCF) we wanted to share some news and feedback of this great event!

Check out other days:

Kubecon Europe 2020 - Day 2

Kubecon Europe 2020 - Day 3

Kubecon Europe 2020 - Day 4

This virtual event is spread over four days including keynotes, lightning talks, conference sessions across 16 tracks, tutorials, and co-located events. It also includes an interactive Sponsor Showcase, attendee collaboration and networking tools...

All sessions will be recorded and available in the CNCF YouTube channel 8 weeks after the conference.

And congratulation to the Kubecon team for the virtual lobby app. It is not easy to represent such an event in a virtual way, well done !

Here are some feedbacks on some sessions, lightning Talk and tutorials we assisted:

Tutorial: Getting Started With Cloud Native Security

By Liz Rice (Vice President, Open Source Engineering, Aqua Security) and Michael Hausenblas (Developer Advocate, Amazon Web Services)

A very interesting tutorial showing how an attacker can exploit a vulnerability: https://tutorial.kubernetes-security.info/ and what are the possible remediations using different approaches and tools.

There are several Kubernetes attack vectors:

They are several ways to secure your Kubernetes cluster and its components:


Multiple solutions for vulnerability scanning are available. This workshop uses the open source scanner Trivy.

Where to scan for vulnerabilities:

  • CI/CD: One way to "shift left" security is to include vulnerability scanning as an automatic step in CI/CD. Typically after the docker build you can have a stage that will scan your image.

  • Admission controllers: An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. So in the context of image scanning it can be used to prevent deploying a container image with known vulnerabilities.

  • Live workloads: New vulnerabilities are found all the time so you will need to regularly check if your running images are safe.

In the demo, Starboard was used. It is a tool for running security tools, including Trivy, within your Kubernetes cluster. This is an easy way to create and view scans of the container images used by your running workloads. Example (CLI) :

kubectl starboard init ## Add CRDs
kubectl starboard find vulns kind/name
kubectl get vulns  --show -labels kind/name

Kubernetes cluster configuration

  • The CIS Benchmark: An objective, consensus-driven security guideline for Kubernetes.

  • Kube-bench: is a Go application that implements the CIS Benchmark and checks whether Kubernetes is deployed securely. There are three output states (Pass, Fail, Info) to indicate test results.


  • Policies are an important tool defining what is or is not allowed in the Kubernetes clusters

  • Principle of least privilege: requires that every module must be able to access only the information and resources that are necessary for its legitimate purpose.

  • Security Context: A security context defines privilege and access control settings for a Pod or Container (like running as privileged user or not, Linux Capabilities, …)

  • Network Policies: A network policy is a specification of how sets of Pods are allowed to communicate with each other and with other network endpoints. NetworkPolicy resources use labels to select Pods and define rules which specify what traffic is allowed to/from the selected Pods

  • OPA: is a general-purpose policy engine that comes with a rule-based policy language called Rego. The goal here is to define and enforce policies like: "Deny any image that doesn’t come from a trusted registry". This project is also based on Admission Controllers Gatekeepers (a CRD based : open-policy-agent/gatekeeper )


Using GitOps brings security out of the box:

  • Git being the source of truth, you benefit from RBAC, traceability and auditing.

  • It is based on Pull Requests so it enforces reviewers and communication