Dev opsec dockerimage_patch_n_lifecyclemanagement_

Kubernetes Application Life Cycle
(patch management)
2018/12/13
#NSD18
DevSecOps
Container Image :
“Application LifeCycle Management”
sed /sLifeCycle/Patch/g
netsecure-day.fr
2018/12/13

(patch management)
2018/12/13
#NSD18
Moi : Charles Sabourdin
Javaiste
Linuxien
Devoxx France
ParisJUG
OpenSource
Architect
Dev/Ops
@kanedafromparis
https://github.com/kanedafromparis/
https://github.com/kanedafromparis
- 45:00

(patch management)
2018/12/13
#NSD18
Sommaire
I. Reminder
A. Docker
1. intro
2. isolation
3. layers
B. Kubernetes
1. generic
2. deployment
C. Development pipeline (security focus)
II. Application life cycle
A. Scanning tools
B. Too much technos
III. Proposed solution
A. 1,2,3 Hosting
B. Pitfalls

(patch management)
2018/12/13
#NSD18
Docker Engine uses namespaces such as the following on Linux:
● The pid namespace: Process isolation (PID: Process ID).
● The net namespace: Managing network interfaces (NET: Networking).
● The ipc namespace: Managing access to IPC resources (IPC:
InterProcess Communication).
● The mnt namespace: Managing filesystem mount points (MNT: Mount).
● The uts namespace: Isolating kernel and version identifiers. (UTS: Unix
Timesharing System).
Namespaces
Docker uses a technology called namespaces to provide the isolated workspace called the container.
When you run a container, Docker creates a set of namespaces for that container.
These namespaces provide a layer of isolation. Each aspect of a container runs in a separate namespace
and its access is limited to that namespace.
I. Reminder : Docker
sources : https://docs.docker.com/engine/docker-overview/#the-underlying-technology
https://en.wikipedia.org/wiki/Linux_kernel

(patch management)
2018/12/13
#NSD18
Control groups
Docker Engine on Linux also relies on another technology called control groups (cgroups). A cgroup
limits an application to a specific set of resources. Control groups allow Docker Engine to share
available hardware resources to containers and optionally enforce limits and constraints. For
example, you can limit the memory available to a specific container.
Union file systems
Union file systems, or UnionFS, are file systems that operate by creating layers, making them very
lightweight and fast. Docker Engine uses UnionFS to provide the building blocks for containers.
Docker Engine can use multiple UnionFS variants, including AUFS, btrfs, vfs, and DeviceMapper.
Container format
Docker Engine combines the namespaces, control groups, and UnionFS into a wrapper called a
container format. The default container format is libcontainer. In the future, Docker may support other
container formats by integrating with technologies such as BSD Jails or Solaris Zones.
Isolation
sources : https://docs.docker.com/engine/docker-overview/#the-underlying-technology
https://en.wikipedia.org/wiki/Cgroups

(patch management)
2018/12/13
#NSD18
Union file systems (again)
Union file systems, or UnionFS, are file systems that operate by creating layers,
making them very lightweight and fast. Docker Engine uses UnionFS to provide the
building blocks for containers. Docker Engine can use multiple UnionFS variants,
including AUFS, btrfs, vfs, and DeviceMapper.
Container format
A Docker image is built up from a series of layers. Each layer represents an
instruction in the image’s Dockerfile. Each layer except the very last one is read-only.
Each layer is only a set of differences from the layer before it. The layers are stacked
on top of each other. When you create a new container, you add a new writable layer
on top of the underlying layers. This layer is often called the “container layer”.
All changes made to the running container, such as writing new files, modifying
existing files, and deleting files, are written to this thin writable container layer.
Layers
sources : https://docs.docker.com/storage/storagedriver/#images-and-layers

(patch management)
2018/12/13
#NSD18
Breadcrumb
Operating System
Toolings / Utils
Language Toolings
Application Toolings
Frameworks / external libs
Application code
Operating System (Docker Image)

(patch management)
2018/12/13
#NSD18
Docker Image Docker
Image
Docker
Image
Docker Image Docker Image
Breadcrumb
Toolings / Utils
Language Toolings
Application code
Alpine Base Image
OpenJDK 8
Tomcat Wildfly
App lib
App 3
Apache httpd 2.4
PHP 7.1 PHP 5.6
Drupal Wordpress
App 1 App 4
Spring
boot
Operating System
App
lib 2
App 2

(patch management)
2018/12/13
#NSD18
Docker Images
A recipe or template for creating Docker containers. It includes the steps for
installing and running the necessary software
Docker Container
Like a tiny virtual machine that is created from the instructions found within the
Docker image
Docker Client
Command-line utility or other tool that takes advantage of the Docker API
(docs.docker.com/ reference/api/docker_remote_api) to communicate with a
Docker daemon
Glossary
sources : https://docs.docker.com/glossary/
https://dzone.com/refcardz/getting-started-with-docker-1
Docker Host
A physical or virtual machine that is running a Docker daemon and contains cached images as well as runnable containers created from
images
Docker Registry
A repository of Docker images that can be used to create Docker containers. Docker Hub (hub.docker.com) is the most popular social
example of a Docker repository.

(patch management)
2018/12/13
#NSD18
● Agile application creation and deployment: Increased ease and efficiency
of container image creation compared to VM image use.
● Continuous development, integration, and deployment
● Dev and Ops separation of concerns
● Environmental consistency across development, testing, and production
● Application-centric management: Raises the level of abstraction from
running an OS on virtual hardware to running an application on an OS
using logical resources.
● Loosely coupled, distributed, elastic, liberated micro-services
● Resource isolation: Predictable application performance.
● Resource utilization: High efficiency and density.
Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both
declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely
available.
Kubernetes
I. Reminder : Kubernetes
sources : https://kubernetes.io/docs/concepts/architecture/cloud-controller/
https://kubernetes.io/blog/2018/07/18/11-ways-not-to-get-hacked/

(patch management)
2018/12/13
#NSD18
Master
The machine that controls Kubernetes nodes. This is where all task assignments originate.
Node
These machines perform the requested, assigned tasks. The Kubernetes master controls
them.
Pod
A group of one or more containers deployed to a single node. All containers in a pod share an
IP address, IPC, hostname, and other resources. Pods abstract network and storage away
from the underlying container. This lets you move containers around the cluster more easily.
Kubelet
This service runs on nodes and reads the container manifests and ensures the defined
containers are started and running.
Glossary
sources : https://www.redhat.com/en/topics/containers/what-is-kubernetes
Replication controller
This controls how many identical copies of a pod should be running somewhere on the cluster.
Service
This decouples work definitions from the pods. Kubernetes service proxies automatically get service requests to the right pod—no matter
where it moves to in the cluster or even if it’s been replaced.

(patch management)
2018/12/13
#NSD18
A container is an instanciate executable
isolated process
A container repository is a library of image.
A Kubernetes Pod (PO) is a group of one or
more containers.
A service (SVC) is named mapping to pod
Object
sources : https://github.com/kanedafromparisfriends/icones_ocp_kube
A ReplicatSet (RS) create and maintain the pod
declaration that will instantiate pods replica
(docker images) that will provide services.
A Deployment (Deploy) create the ReplicatSet that
will provide services.
Persistent Volume (PV) is a piece of networked
storage in the cluster.
Persistent Volume Claim (PVC) is a reservation of a
Persistent Volume into a namespace / project
...

(patch management)
2018/12/13
#NSD18
The following are typical use cases for Deployments:
● Create a Deployment to rollout a ReplicaSet. The ReplicaSet creates Pods in the background. Check the status of the rollout to see if
it succeeds or not.
● Declare the new state of the Pods by updating the PodTemplateSpec of the Deployment. A new ReplicaSet is created and the
Deployment manages moving the Pods from the old ReplicaSet to the new one at a controlled rate. Each new ReplicaSet updates
the revision of the Deployment.
Deployment
sources : https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
● Rollback to an earlier Deployment revision if the current
state of the Deployment is not stable. Each rollback updates
the revision of the Deployment.
● Scale up the Deployment to facilitate more load.
● Pause the Deployment to apply multiple fixes to its
PodTemplateSpec and then resume it to start a new rollout.
● Use the status of the Deployment as an indicator that a
rollout has stuck.
● Clean up older ReplicaSets that you don’t need anymore.

(patch management)
2018/12/13
#NSD18
En pratique (et Yaml)
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "3"
kubernetes.io/change-cause: "blabla..."
creationTimestamp: 2018-01-27T18:17:26Z
generation: 5
labels:
run: logversion
name: logversion
spec:
minReadySeconds: 15
progressDeadlineSeconds: 300
replicas: 3
selector:
matchLabels:
run: logversion
strategy:
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
type: RollingUpdate
...
template:
metadata:
creationTimestamp: null
labels:
run: resourcesmonger
spec:
containers:
- image: https://myregistry.org/kanedafromparis/logversion:3.1
imagePullPolicy: IfNotPresent
name: logversion
ports:
- containerPort: 8080
protocol: TCP
resources:
...
livenessProb
...
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
...

(patch management)
2018/12/13
#NSD18
Docker
Image
Docker Image Docker
Image
Docker
Image
Breadcrumb
Infrastructure
Operating System (Node OS)
Toolings / Utils
Language Toolings
Application code
Alpine Base Image
OpenJDK 8
Tomcat Wildfly
App lib
App 2
App 3
Apache httpd 2.4
PHP 7.1 PHP 5.6
Drupal Wordpress
App 1 App 4
Spring|
boot
https://myregistry.or
g/.../App1:x.y
../App2:x.y ../App3:x.y ../App4:x.y ../App5:x.y
Docker
Image
kubelet

(patch management)
2018/12/13
#NSD18
Dev Local
Developper need to develop project on it,s local machine (unit test, debug,
etc…)
Dev on cluster
In order to check some integration issue, Dev can develop into a dedicated
namespace. This namespace can host component and resources identical to
production
CI on cluster
Automated build/test system (Jenkins) catch commit in order to build the future
docker artifact(s) that will be propagated to the QA namespaces
QA on cluster
Automated test are executed on a dedicated namespaces
Staging on cluster (optional)
A referential namespace can be used for load testing, human validation and pre-
visualisation
Production on cluster
A production namespace host the project with the necessary security
constraintes
s/Development/Deployment/g pipeline
I. Reminder : Development pipeline
sources : Containerizing Continuous Delivery in Java by Daniel Bryant

(patch management)
2018/12/13
#NSD18
SonarQube® is an automatic code review tool to detect bugs, vulnerabilities and
code smells in your code. It can integrate with your existing workflow to enable
continuous code inspection across your project branches and pull requests.
Continuous Inspection
SonarQube provides the capability to not only show health of an application but
also to highlight issues newly introduced. With a Quality Gate in place, you can
fix the leak and therefore improve code quality systematically.
Detect Tricky Issues
Our code analyzers are equipped with powerful path sensitive dataflow engines
to detect tricky issues such as null-pointers dereferences, logic errors, resource
leaks..
Centralize Quality
One place to provide a shared vision of code quality for developers, tech leads,
managers and executives in charge of a few to a few thousands projects and
also to act as a toll gate for application promotion or release
QA : Exemple SonarQube
sources : https://www.sonarqube.org/

(patch management)
2018/12/13
#NSD18
Some of ZAP's functionality:
● Man-in-the-middle Proxy
● Traditional and AJAX spiders
● Automated scanner
● Passive scanner
● Forced browsing
● Fuzzer
● Dynamic SSL certificates
● Smartcard and Client Digital Certificates support
● Web sockets support
● Support for a wide range of scripting languages
● Plug-n-Hack support
● Authentication and session support
● Powerful REST based API
● Automatic updating option
● Integrated and growing marketplace of add-ons
QA : Example ZappProxy
sources :
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project#tab=Functionality

(patch management)
2018/12/13
#NSD18
Continuous Integration
the practice of frequently integrating one's new or changed code with the existing code repository – should occur frequently enough that
no intervening window remains between commit and build, and such that no errors can arise without developers noticing them and
correcting them immediately.
Notice : Maturity level
sources : DevOps with OpenShift by Stefano Picozzi, Mike Hepburn, and Noel O’Connor
https://en.wikipedia.org/wiki/Continuous_delivery, https://en.wikipedia.org/wiki/Continuous_deployment, https://en.wikipedia.org/wiki/Continuous_integration
Continuous delivery (CDE)
A software engineering approach in which teams
produce software in short cycles, ensuring that the
software can be reliably released at any time and,
when releasing the software, doing so manually.
Continuous deployment (CD)
A software engineering approach in which software
functionalities are delivered frequently through
automated deployments.
- 30:00

(patch management)
2018/12/13
#NSD18
DEV
(NS)
Digression: version tag versus purpose tag
img:1.2.1
QA
(NS)
STG
(NS)
PROD
(NS)
img:1.2.0 img:1.1.1 img:1.1.1
DEV
(NS)
img:dev
QA
(NS)
STG
(NS)
PROD
(NS)
img:qa img:stg img:prod
imagePullPolicy: Always

(patch management)
2018/12/13
#NSD18
sources : https://devops.com.vn/2018/117/
Application lifecycle (example)

(patch management)
2018/12/13
#NSD18
sources : https://www.lemondeinformatique.fr/actualites/lire-atlassian-fait-pousser-ses-offres-devops-68588.html

(patch management)
2018/12/13
#NSD18
CVE happens
sources : https://www.cvedetails.com/

(patch management)
2018/12/13
#NSD18
3 years Lifecycle of a website application (example)
Patch

(patch management)
2018/12/13
#NSD18
Application lifecycle
Feature developpement through application configuration or coding is only a phase of the Application life cycle. This phase
can be a big or a small part of the application life.
Several phase are also necessary within the application lifecycle :
- Feature development with testing and validation
This phase can happen several time during the application life.
- Deployment
- Security update
- Decommission
This phase should only happen once.
The manpower necessary for any of theses phases vary a lot.
Depending of the complexity of the application, the disponibility of
the knowledgeable parties, the level of automatisation
This is why an application need to have a application owner
accountable over the entire application lifecycle.

(patch management)
2018/12/13
#NSD18
Scan tools: downstream / upstream
Security tools can give you inside knowledge of your image and
potential security vulnerability
Most are hook on you registry or can have local agent that will
highlight most of you CVE issue.
Usually they scan package (.rpm, .deb, .apk,...) but not tar.gz
and mostly not application library.
They can have various trigger and can set various trigger
- email alert
- automatic rebuild
- block pull
- ...

(patch management)
2018/12/13
#NSD18
Docker
Image
Docker Image Docker
Image
Docker
Image
Breadcump
Infrastructure
Toolings / Utils
Language Toolings
Application code
Alpine Base Image
OpenJDK 8
Tomcat Wildfly
App lib
App 2
App 3
Apache httpd 2.4
PHP 7.1 PHP 5.6
Drupal Wordpress
App 1 App 4
Spring|
boot
g/.../App1:x.y
Docker
Image
kubelet
Detected by most vulnerability
scanner
Often out of scope
- 20:00

(patch management)
2018/12/13
#NSD18
Application lifecycle : PHP
PHP Component
● httpd
● nginx
● composer
● symphony
● drupal
● wordpress
● PhpUnit

(patch management)
2018/12/13
#NSD18
Application lifecycle : Java
Java
● openjdk
● oraclejdk
● azul
● ant
● maven
● graddle
● spring boot
● vert-x
● war+tomat
● war+tomEE
● ear+tomEE
● ...

(patch management)
2018/12/13
#NSD18
Application lifecycle : nodejs
Nodejs
● v8
● deno
● npm
● webpack
● bower
● espress.js
● mongoose
● lodash
● Jest
● phatomejs
● chomium
● ...

(patch management)
2018/12/13
#NSD18
Application lifecycle : Scala
Sacla
● sbt
● …
● Play
● Sparks
● ...

(patch management)
2018/12/13
#NSD18
It can rapidly became unmanageable

(patch management)
2018/12/13
#NSD18
Docker
Image
Docker Image Docker
Image
Docker
Image
Breadcrumb
Infrastructure
Toolings / Utils
Language Toolings
Application code
Alpine Base Image
OpenJDK 8
Tomcat Wildfly
App lib
App 2
App 3
Apache httpd 2.4
PHP 7.1 PHP 5.6
Drupal Wordpress
App 1 App 4
Spring|
boot
g/.../App1:x.y
Docker
Image
kubelet
Usually ops scope
Usually Dev scop

(patch management)
2018/12/13
#NSD18
Base image : A transition image destined to process program
code in order to create an application image.
Application image : An image use into kubernetes that
provide the custom service developed by the company. It can
came from a base image or a custom dockerfile.
Proposed vocabulary
Still image : An image used into kubernetes cluster with only
configuration adaptation. A still image is based on non-internal
source code or binaries.

(patch management)
2018/12/13
#NSD18
Docker Image Docker
Image
Docker
Image
Breadcrumb
Infrastructure
Toolings / Utils
Language Toolings
Application code
Alpine Base Image
OpenJDK 8
Tomcat Wildfly
App lib
App 2
App 3
Apache httpd 2.4
PHP 7.1 PHP 5.6
Drupal Wordpress
App 1 App 4
Spring|
boot
g/.../App1:x.y
BaseImage
ApplicationImage
StillImage

(patch management)
2018/12/13
#NSD18
1,2,3 hosting
1 : Project will use Dockerfile using our base image & still
image proposed and maintain by the host team (ops)

(patch management)
2018/12/13
#NSD18
1,2,3 hosting
2 : Project will use its own Dockerfile but will be in charge of
maintenance (specially security)

(patch management)
2018/12/13
#NSD18
1,2,3 hosting
2 : Project will use its own Dockerfile but will be in charge of
maintenance (specially security)
3 : Project will use third parties image (signed image)

(patch management)
2018/12/13
#NSD18
Pitfalls
- 10:00

(patch management)
2018/12/13
#NSD18
Pitfalls
● Absence of a project Owner

(patch management)
2018/12/13
#NSD18
Pitfalls
● Tooling focus / automation freak

(patch management)
2018/12/13
#NSD18
Pitfalls
● Lack of communication (specially between dev team and hosting team)

(patch management)
2018/12/13
#NSD18
Pitfalls
● Build to Prod (no test)

(patch management)
2018/12/13
#NSD18
Pitfalls
● Too many version, too many variante

(patch management)
2018/12/13
#NSD18
Pitfalls
● Too many version, too many variante
● Lack of management support / acceptance in rules enforcement

(patch management)
2018/12/13
#NSD18
Thank you
● Questions ?
- 00:00

Dev opsec dockerimage_patch_n_lifecyclemanagement_

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Dev opsec dockerimage_patch_n_lifecyclemanagement_

Similar a Dev opsec dockerimage_patch_n_lifecyclemanagement_ (20)

Más de kanedafromparis

Más de kanedafromparis (6)

Último

Último (20)

Dev opsec dockerimage_patch_n_lifecyclemanagement_