KubeCon: Veiligheid rond images in Kubernetes

Op dag 2 van de KubeCon conferentie zijn er onder andere 2 interessante sessie rond het onderwerp security in Kubernetes.

Security is een onderwerp die zeker meer aandacht zal gaan krijgen en moet krijgen.
Vooral rond kwestsbaarheid van container images, de vertrouwelijkheid van bronnen, de image registries en welke code, libraries en dependencies gebruik worden.

In het geval rond het scannen op kwetsbaarheden code in containers is een standaard om gebruik te maken van CVE databases. Common Vulnerability and Exposures is een databank met informatie over kwetsbaarheden in computersystemen en netwerken.
Het Red Hat Openshift platform kan gecombineerd worden met Red Hat CloudForms, een infrastructureel management platform,  waarin via OpenSCAP images gecontroleerd en gerapporteerd worden op CVE’s. Via het annoteren van images kan via de kubernetes Admission controller eventueel een image deployment blokkeren.

Er beginnen op dit moment steeds meer producten komen die zich door security rond containers richten. Producten als bijv. Black Duck, Twistlock, Aqua Security en Neu Vector (en inmiddels anderen waarschijnlijk). Hierbij zijn de laatste 2 breder inzetbaar en gaan meer naar full-stack beveiliging.

De 2 sessies van vandaag gingen niet zo zeer op kwetsbaarheid scanning van code in.
Hoe krijg je grip over wat je in je omgeving hebt draaien en hoe zorg je ervoor dat je vertrouwde code hebt draaien in productie.

Establishing image provenance and security in Kubernetes door Container Solutions.

Neem elke container in uw Kubernetes-cluster. Wat kun je erover zeggen en met welk niveau van zekerheid? Weet jij waar het vandaan kwam? Kan een aanvaller het aanpassen? Is het up-to-date? Kun je de exacte revisie van de code waar de afbeelding vanaf is gebouwd identificeren?

Welke garanties biedt Kubernetes en wat u kunt doen om een ​​veiligde en betrouwbare werkstroom voor het implementeren en bijwerken van afbeeldingen tot stand te brengen.

Onderwerpen en tooling die worden behandeld, omvatten: – afbeeldingen op een herhaalbare manier bouwen met BuildKit of Bazel – distributie van afbeeldingen via registers – het verifiëren van de herkomst met beveiligde hashes en Notary / TUF.

Securing your Kubernetes delivery pipeline with Notary and Tuf door IBM.

Hoe zorgen ondernemingen ervoor dat de code vertrouwt is die in uw productieomgeving wordt gebruikt en dat er niet door kwaadwillenden is geknoeid.

Notary zorgt voor meer veiligheid in image deployment door het engineers gemakkelijk te maken inhoud te publiceren en te verifiëren.

Met Notary kunnen uitgevers hun content offline met beveiligde sleutels ondertekenen en naar een Notary server verzenden. Consumenten die de openbare sleutel van de uitgever via een beveiligd kanaal hebben verkregen, kunnen vervolgens communiceren met een Notary server , waarbij ze alleen op de sleutel van de uitgever vertrouwen om de geldigheid en integriteit van de ontvangen inhoud te bepalen.

Enkele referenties (door Andrian Mouat):

Trow https://trow.io
Grafeas https://grafeas.io/
OCI Annotationshttps://github.com/opencontainers/image-spec/blob/master /annotations.md
Release Engineering (from Google SRE Book) https://landing.google.com/sre/book/chapters/release-engineering.html
AlwaysPullImages Admission Controller
https://kubernetes.io/docs/admin/admission-controllers/#alwayspullimages
ImageStreams in OpenShift https://blog.openshift.com/image-streams-faq/
Docker EE https://www.docker.com/enterprise-edition
Notary https://github.com/theupdateframework/notary
Weave Flux https://www.weave.works/oss/flux/
Clair https://github.com/coreos/clair
Aqua https://www.aquasec.com/
NeuVector https://neuvector.com/
Twistlock https://www.twistlock.com/
Bazel https://bazel.build/
Kaniko https://github.com/GoogleContainerTools/kaniko

About the author

Eric van Beek


>