SlideShare a Scribd company logo
1 of 23
Understanding Docker
Ecosystem And Vulnerabilities
Points
By Abdul khan
Author
• Abdul Khan
• IT Consultant based in Manchester, UK
• Engineering Lead, Executive, Technologist, Architect
• IT experience, within the private and public sectors (Retail, Banking, Digital, Insurance, M.O.D., HMRC, Aviation, Telecommunication,
Housing Associations, Education, Travel, and Pharmaceutical companies). Excellent architectural and strong DevOps experience with
proven-track record of delivering E2E, B2B and B2C solution on regional and global programs.
• SME in specializing in providing integration, data migration, digital transformations to the cloud solutions (Azure and AWS)
• Wealth of experience in global projects across EMEA, ASPAC and LATAM
• Liked in profile https://www.linkedin.com/in/abdul-khan-uk/
Accreditations
Thank you to my good friend and colleague for reviewing, adding value, sharing their vast experience and
knowledge.
• Steve Lampton (IT Consultant, Cloud SME) specialising in NetOps, DevOps and SecOps
Audience
Main Audience
• Technical Managers
• Architects
• Technical Leads and DevOps, NetOps an d SecOps
Assumptions
• Reader has some knowledge of Docker containerisation, and cloud platforms
technologies.
Understanding Docker Ecosystem
And Vulnerabilities Points
Content
1. What is Docker EcoSystem?
2. Containerisation Technology
3. Main Advantages of Docker
4. Docker and Containerization
5. Service Discovery and Global Configuration Stores
6. Service Discovery Responsibilities
7. Scheduling, Cluster Management, and Orchestration
8. Identifying Key Vulnerabilities
9. Understand Docker Ecosystem Vulnerable End Points
10. Images Risks Within Container
11. Register Risks within Containers
12. Orchestrator Risks Within Containers
13. Run-Time Risks Of Containers
14. Hosts Risks Within Containers
1. What is Docker EcoSystem?
• Containerization is the process of distributing and deploying applications in a portable and
predictable way. This is done by packaging components and their dependencies into standardized,
isolated, lightweight process environments called containers.
• Many organizations are now interested in designing applications and services that can be easily
deployed to distributed systems, allowing the system to scale easily and survive machine and
application failures. Docker, a containerization platform developed to simplify and standardize
deployment in various environments, was largely instrumental in spurring the adoption of this
style of service design and management.
• A large amount of software has been created to build on this ecosystem of distributed container
management.
VM
2. Containerisation Technology
Type-1 Hypervisor
App
Libs
Guest OS
Hypervisor
Hardware
VM
App
Libs
Guest OS
VM
App
Libs
Guest OS
VM
App
Libs
Guest OS
Hypervisor
Host OS
VM
App
Libs
Guest OS
VM
App
Libs
Guest OS
Hardware
VM
App
Libs
Guest OS
Docker Daemon
Host Libraries
VM
App
Libs
Guest OS
VM
App
Libs
Guest OS
Host OS
Hardware
Conterinersation is a lightweight alternative to full machine virtualization, that involves
encapsulating an application in a container with its own operating environment.
Type-2 Hypervisor Containers
3. Main Advantages of Docker
• Lightweight resource utilization: instead of virtualizing an entire operating
system, containers isolate at the process level and use the host’s kernel.
• Portability: all of the dependencies for a containerized application are bundled
inside of the container, allowing it to run on any Docker host.
• Predictability: The host does not care about what is running inside of the
container and the container does not care about which host it is running on. The
interfaces are standardized and the interactions are predictable.
4. Docker and Containerization
• Docker is the most common containerization software in use today. While other containerizing systems exist,
Docker makes container creation and management simple and integrates with many open source projects.
• The diagram below shows how containers relate to the host system. Containers isolate individual applications
and use operating system resources that have been abstracted by Docker. In detailed view containers can be
built by “layering”, with multiple containers sharing underlying layers, decreasing resource usage.
App
A
App
B
Kernel
HOST 1
App
B
App
C
OS
Layer 2 (B)
App
C
Layer 2 (B)
Layer 2 (Shared)
Layer 1 (Shared)
5. Service Discovery and Global Configuration
Stores (1/2)
• Service discovery component strategy is aimed at making container deployments
scalable and flexible.
• Service discovery allows containers to find out about the environment without
administrator intervention.
• Service discovery finds connection information for the components and they can register
themselves so that other tools know that they are available.
• These tools also typically function as globally distributed configuration stores where
arbitrary config settings can be set for the services operating in your infrastructure.
5. Service Discovery and Global Configuration
Stores 2/2
• The simplified view below shows the flow in which one application registers its connection information with
the discovery service system. Once registered, other applications can query the discovery service to find out
how to connect to the application
Service Discover
App
A
1
App
A
2 3
4
HOST 1
192.XXX.1.2
HOST 1
192.XXX.1.3
Connection
Request
App A is at
192.XXX.1.2
Where is App A?Register App A
192.XXX.1.2
6. Service Discovery Responsibilities
• The key responsibilities of service discovery stores are:
• Allowing applications to obtain the data needed to connect with to the services they depend on.
• Allowing services to register their connection information for the above purpose.
• Providing a globally accessible location to store arbitrary configuration data.
• Storing information about cluster members as needed by any cluster management software.
• Some popular service discovery tools and related projects are:
• etcd : service discovery / globally distributed key-value store
• consul : service discovery / globally distributed key-value store
• zookeeper: service discovery / globally distributed key-value store
• crypt : project to encrypt etcd entries
• confd: watches key-value store for changes and triggers reconfiguration of services with new values
7. Scheduling, Cluster Management, and Orchestration
• Docker Container orchestration tool (Docker Swam) can package and run the
application as container
• Docker Swam fits into a cluster Management, A mix docker-compose, swarm, that
overlay network and a good service discovery tool such as etcd or consul can be
used for managing the cluster of docker containers
• Schedulers are responsible for starting containers on the available hosts.
8. Identifying Key Vulnerabilities
• Insecurity production system configuration
• Vulnerabilities in the image distribution, verification, decompression, storage
process
• Vulnerabilities inside the images
• Vulnerabilities directly linked to Docker or Libcointainer
• Vulnerabilities of the Linux kernel. Libcontainer
CLIENT
Above are the key endpoints throughout this Docker ecosystem that can be
breached and can be vulnerable at any given point which may lead to malicious
or unintended consequences.
9. Understand Docker Ecosystem Vulnerable End Points (1/2)
DOCKER HOST REGISTRY
docker_build
Container Imagesdocker_build
1
X
X
Docker Daemon
Passing secrets from host to container
using environment variables at run
time
X
4
X
3
Running containers as
root
Running containers with
the privileged flag
Unsecured access to
the Docker API
2
Insecure image registries
X
5
X6
Unsecured access
to the Docker
host(s)
Images
• Unsecured access to the Docker API
• Users added to the “Docker” group can use all Docker functions that utilize images and containers.
• Passing secrets from host to container using environment variables at run time
• Secrets can be passed through to the Docker container at run time using the “-e“ flag. These secrets have to
be passed through in clear text. Automation scripts should be define with variables. Running containers with
the privileged “—privileged” flag provides the container with direct access to host elements such as devices
and other pieces of hardware.
• Running containers as root
• By not declaring a user for each container or using the “-user” flag, container users have access to the same
GUID and UID as the host machine, even if the passwords are different. This can lead to the container(s)
gaining access to files on the host machine if they are mapped within the container.
• Insecure image registries
• All containers come from one or more registries. With unsecured access to registries, an attacker can
manipulate your images to add code – without your approval or knowledge. Use secure your registries with
SSL/TSL, create distinct users, store user(s) and certificate information in a secure vault and regularly rotate
credentials.
• Unsecured access to the Docker host(s)
• All efforts to protect Docker APIs, image registries, All SSH and web page connections to your
Docker/orchestration host machine should be monitored and recorded, and all root accounts should be
managed, stored and regularly rotated in a secure vault.
9. Understand Docker Ecosystem Vulnerable End Points (2/2)
• Image vulnerabilities
• Images are effectively static archive files that include all the components used to run a given application, components within an image may
be missing critical security updates or are otherwise outdated. A common risk in containerized environments is deployed containers having
vulnerabilities because the version of the image used to generate the containers has vulnerabilities.
• Image configuration
• In addition to software defects, images may also have configuration defects. For example, an 719 image may not have a user defined and
thus not take advantage of the defense in depth provided 720 by user namespaces. As another example, an image may include an SSH
daemon, which exposes 721 the container to unnecessary network risk. Much like in a traditional server or VM, where a poor 722
configuration can still expose a fully up-to-date system to attack, so too can a poorly configured 723 image increase risk even if all the
included components are up-to-date.
• Embedded malware
• Because images are just collections of files packaged together, malicious files could be included 726 intentionally or inadvertently within
them. Such malware would have the same capabilities as 727 any other component within the image and thus could be used to attack
other containers or hosts 728 within the environment. A possible source of embedded malware is the use of base layers and 729 other
images provided by third parties of which the full provenance is not known.
• Embedded secrets
• Many applications require secrets to enable secure communication between components. For 732 example, a web application may need a
username and password to connect to a backend 733 database. Other examples of embedded secrets include connection strings, SSH
private keys, and 734 X.509 private keys. When an app is packaged in a container, these secrets can be embedded 735 directly into the
image. However, this practice creates a security risk because anyone with access 736 to the image file can easily parse it to learn these
secrets.
• Image trust
• One of the most common high-risk scenarios in any environment is the execution of untrusted 739 software. The portability and ease of
reuse of containers increase the temptation for teams to run 740 images from external sources that may not be well validated or
trustworthy. For example, when 741 troubleshooting a problem with a web application, a user may find another version of that 742
application available in an image provided by a third party. Using this externally provided image 743 results in the same types of risks that
external software traditionally has, such as introducing 744 malware, leaking data, or including components with vulnerabilities.
10. Images Risks Within Container
• Insecure connections to registries
• Images often contain sensitive components like an organization’s proprietary software and 748
embedded secrets. If connections to registries are performed over insecure channels, the contents
749 of images are subject to the same confidentiality risks as any other data transmitted in the
clear. 750 There is also an increased risk of man-in-the-middle attacks that could intercept network
traffic 751 intended for registries and steal developer or administrator credentials, provide
fraudulent or 752 outdated images to orchestrators, etc.
• Stale images in registries
• Because registries are typically the source location for all the images an organization deploys, 755
over time the set of images they store can include many vulnerable, out-of-date versions. While
756 these vulnerable images do not directly pose a threat simply by being stored in the registry,
they 757 increase the likelihood of accidental deployment of a known-vulnerable version.
• Insufficient authentication and authorization restrictions
• Because registries may contain images used to run sensitive or proprietary applications and to 760
access sensitive data, insufficient authentication and authorization requirements can lead to
761intellectual property loss and expose significant technical details about an application to an 762
attacker. Even more critically, because registries are typically trusted as a source of valid, 763
approved software, compromise of a registry can potentially lead to compromise of downstream
764 containers and hosts.
11. Register Risks within Containers
• Unbounded administrative access
• Historically, many orchestrators were designed with the assumption that all users interacting 768 with them would be administrators and those administrators should
have environment-wide 769 control. However, in many cases, a single orchestrator may run many different apps, each 770 managed by different teams, and with
different sensitivity levels. If the access provided to users 771 and groups is not scoped to their specific needs, a malicious or careless user could affect or 772 subvert
the operation of other containers managed by the orchestrator.
• Unauthorized access
• Orchestrators often include their own authentication directory, which may be separate from the 775 typical directories already in use within an organization. This can
lead to weaker account 776 management practices and ‘orphaned’ accounts in the orchestrator because these systems are less 777 rigorously managed. Because
many of these accounts are highly privileged within the 778 orchestrator, compromise of them can lead to systemwide compromise. 779 Another concern regarding
unauthorized access is the misuse of credentials, such as an attacker 780 getting access to a password through social engineering or other means, then reusing that
781 password to access the orchestrator.
• Poorly separated inter-container network traffic
• In most containerized environments, traffic between individual nodes is routed over a virtual 784 overlay network. This overlay network is typically managed by the
orchestrator and is often 785 opaque to existing network security and management tools. For example, instead of seeing 786 database queries being sent from a web
server container to a database container on another host, 787 traditional network filters would only see encrypted packets flowing between two hosts, with no 788
visibility into the actual container endpoints, nor the traffic being sent. This can create a security 789 ‘blindness’ scenario in which organizations are unable to
effectively monitor traffic within their 790 own networks.
• Potentially even more critical is the risk of traffic from different applications sharing the same 792 virtual networks. If apps of different sensitivity levels, such as a
public-facing web site and an 793 internal treasury management app, are using the same virtual network, sensitive internal apps 794 may be exposed to greater risk
from network attack. For example, if the public-facing web site is 795 compromised, attackers may be able to use shared networks to attack the treasury app.
• Mixing of workload sensitivity levels
• Orchestrators are typically focused primarily on driving the scale and density of workloads. This 798 means that, by default, they can place workloads of differing
sensitivity levels on the same host. 799 For example, in a default configuration, an orchestrator may place a container running a public-800 facing web server on the
same host as one processing sensitive financial data, simply because 801 that host happens to have the most available resources at the time of deployment. In the
case of a 802 critical vulnerability in the web server, this can put the container processing sensitive financial 803 data at significantly greater risk of compromise.
• Orchestrator
• Many orchestrators exist and each supports a wide variety of configurations. Weak orchestrator 806 configurations can expose the orchestrator and all other
container technology components to 807 increased risk. Examples of possible consequences include: 808
• • Unauthorized hosts joining the cluster and running containers 809
• • The compromise of a single cluster host implying compromise of the entire cluster—for 810 example, if the same key pairs used for authentication are shared across all
nodes 811
• • Communications between the orchestrator and DevOps personnel, administrators, and 812 hosts being unencrypted and unauthenticated node trust
12. Orchestrator Risks Within Containers
13. Run-Time Risks Of Containers
• Vulnerabilities within the runtime software
• While relatively uncommon, vulnerabilities within the runtime software are particularly 816 dangerous if they allow ‘container escape’ scenarios in which malicious software
can attack 817 resources in other containers and the host OS itself. An attacker may also be able to exploit 818 vulnerabilities to compromise the runtime software itself, and
then alter that software so it allows 819 the attacker to access other containers, monitor container-to-container communications, etc.
• Unbounded network access from containers
• By default in most container runtimes, individual containers are able to access each other and the 822 host OS over the network. If a container is compromised and acting
maliciously, allowing this 823 network traffic may expose other resources in the environment to risk. For example, a 824 compromised container may be used to scan the
network it is connected to in order to find other 825 weaknesses for an attacker to exploit. This risk is related to that from poorly separated virtual 826 networks, as discussed
in Section 3.3.3, but different because it is focused more on flows from 827 containers to any outbound destination, not on app “cross talk” scenarios. 828
• Egress network access is more complex to manage in a containerized environment because so 829 much of the connection is virtualized between containers. Thus, traffic
from one container to 830 another may appear simply as encapsulated packets while in motion on the network without an 831 understanding of the ultimate source,
destination, or payload. Tools and operational processes 832 that are not container aware are not able to inspect this traffic or determine whether it represents 833 a threat.
• Insecure container runtime configurations
• Container runtimes typically expose many configurable options to administrators. Setting them 836 improperly can lower the relative security of the system. For example, on
Linux container hosts, 837 the set of allowed system calls is often limited by default to only those required for safe 838 operation of containers. If this list is widened, it may
expose containers and the host OS to 839 increased risk from a compromised container. Similarly, if a container is run in privileged mode, 840 it has access to all the devices
on the host, thus allowing it to essentially act as part of the host 841 OS and impact all other containers running on it. 842
• Another example of an insecure runtime configuration is allowing containers to mount sensitive 843 directories on the host. Containers should rarely make changes to the
host OS file system and 844 should almost never make changes to locations like /boot or /etc that control the basic 845 functionality of the host OS. If a compromised
container is allowed to make changes to these 846 paths, it could be used to elevate privileges and attack the host itself as well as other containers 847 running on the host.
• Application vulnerabilities
• Even when organizations are taking the precautious recommended in this guide, containers may 850 still be compromised due to flaws in the apps within them. This is not a
problem with containers 851 themselves, but instead is just the manifestation of typical software flaws within a container 852 environment. For example, a containerized web
app may be vulnerable to cross-site scripting 853 vulnerabilities, and a database front end container may be subject to Structured Query Language 854 (SQL) injection. When
a container is compromised, it can be misused in many ways, such as 855 granting unauthorized access to sensitive information or enabling attacks against other containers
856 or the host OS.
14. Hosts Risks Within Containers
• Large attack surface
• Every host OS has an attack surface, which is the collection of all ways attackers can attempt to 860 access and exploit the host OS’s
vulnerabilities. For example, any network-accessible service 861 provides a potential entry point for attackers, adding to the attack
surface. The larger the attack 862 surface is, the better the odds are that an attacker can find and access a vulnerability, leading to a
863 compromise of the host OS and the containers running on top of it.
• Shared kernel
• Container-specific OSs have a much smaller attack surface than that of general-purpose OSs. For 866 example, they do not contain
libraries and package managers that enable a general-purpose OS to 867 directly run database and web server apps. However,
although containers provide strong 868 software-level isolation of resources, the use of a shared kernel invariably results in a larger
869 inter-object attack surface than seen with hypervisors, even for container-specific OSs. In other 870 words, the level of isolation
provided by container runtimes is not as high as that provided by 871 hypervisors
• Host OS component vulnerabilities
• All host OSs, even container-specific ones, provide foundational system components—for 874 example, the cryptographic libraries
used to authenticate remote connections and the kernel 875 primitives used for general process invocation and management. Like
any other software, these 876 components can have vulnerabilities and, because they exist low in the container technology 877
architecture, they can impact all the containers and applications that run on these hosts.
• Improper user access rights
• Container-specific OSs are typically not optimized to support multiuser scenarios since 880 interactive user logon should be rare.
Organizations are exposed to risk when users log on 881 directly to hosts to manage containers, rather than going through an
orchestration layer. Direct 882 management enables wide-ranging changes to the system and all containers on it, and can 883
potentially enable a user that only needs to manage a specific app’s containers to impact many 884 others.
• Host OS file system tampering
• Insecure container configurations can expose host volumes to greater risk of file tampering. For 887 example, if a container is
allowed to mount sensitive directories on the host OS, that container 888 can then change files in those directories. These changes
could impact the stability and security 889 of the host and all other containers running on it.
- END OF DECK
By Abdul Khan – https://www.linkedin.com/in/abdul-khan-uk/

More Related Content

What's hot

How to containerize at speed and at scale with Docker Enterprise Edition, mov...
How to containerize at speed and at scale with Docker Enterprise Edition, mov...How to containerize at speed and at scale with Docker Enterprise Edition, mov...
How to containerize at speed and at scale with Docker Enterprise Edition, mov...Kangaroot
 
Docker, how to use it. organize a meeting with IBM products...
Docker, how to use it. organize a meeting with IBM products...Docker, how to use it. organize a meeting with IBM products...
Docker, how to use it. organize a meeting with IBM products...Andrea Fontana
 
Here Be Dragons: Security Maps of the Container New World
Here Be Dragons: Security Maps of the Container New WorldHere Be Dragons: Security Maps of the Container New World
Here Be Dragons: Security Maps of the Container New WorldC4Media
 
Novell ZENworks Overview and Futures
Novell ZENworks Overview and FuturesNovell ZENworks Overview and Futures
Novell ZENworks Overview and FuturesNovell
 
Dockercon EU 2015 Recap
Dockercon EU 2015 RecapDockercon EU 2015 Recap
Dockercon EU 2015 RecapLee Calcote
 
VMware - Snapshot sessions - Deploy and manage tomorrow's applications today
VMware - Snapshot sessions  - Deploy and manage tomorrow's applications todayVMware - Snapshot sessions  - Deploy and manage tomorrow's applications today
VMware - Snapshot sessions - Deploy and manage tomorrow's applications todayAnnSteyaert_vmware
 
Containers for Lawyers Richard Fontana
Containers for Lawyers  Richard FontanaContainers for Lawyers  Richard Fontana
Containers for Lawyers Richard FontanaBlack Duck by Synopsys
 
NSS File System Performance, Clustering and Auditing in Novell Open Enterpris...
NSS File System Performance, Clustering and Auditing in Novell Open Enterpris...NSS File System Performance, Clustering and Auditing in Novell Open Enterpris...
NSS File System Performance, Clustering and Auditing in Novell Open Enterpris...Novell
 
Installing and Configuring Novell Conferencing
Installing and Configuring Novell ConferencingInstalling and Configuring Novell Conferencing
Installing and Configuring Novell ConferencingNovell
 
Java Microservices HJUG
Java Microservices HJUGJava Microservices HJUG
Java Microservices HJUGLana Kalashnyk
 
Simplify Your Way To Expert Kubernetes Management
Simplify Your Way To Expert Kubernetes ManagementSimplify Your Way To Expert Kubernetes Management
Simplify Your Way To Expert Kubernetes ManagementDevOps.com
 
Using Novell Sentinel Log Manager to Monitor Novell Applications
Using Novell Sentinel Log Manager to Monitor Novell ApplicationsUsing Novell Sentinel Log Manager to Monitor Novell Applications
Using Novell Sentinel Log Manager to Monitor Novell ApplicationsNovell
 
Cloud Ready for Linux on System z Technical White Paper
Cloud Ready for Linux on System z Technical White PaperCloud Ready for Linux on System z Technical White Paper
Cloud Ready for Linux on System z Technical White PaperIBM India Smarter Computing
 
Web Application Debugging Webinar
Web Application Debugging WebinarWeb Application Debugging Webinar
Web Application Debugging WebinarAVEVA
 
Migrate from Red Hat to SUSE Linux Enterprise Server
Migrate from Red Hat to SUSE Linux Enterprise ServerMigrate from Red Hat to SUSE Linux Enterprise Server
Migrate from Red Hat to SUSE Linux Enterprise ServerNovell
 
Thinking about Jenkins Security
Thinking about Jenkins SecurityThinking about Jenkins Security
Thinking about Jenkins SecurityMark Waite
 
From Zero to Hero: Continuous Container Security in 4 Simple Steps
From Zero to Hero: Continuous Container Security in 4 Simple StepsFrom Zero to Hero: Continuous Container Security in 4 Simple Steps
From Zero to Hero: Continuous Container Security in 4 Simple StepsDevOps.com
 
Docker - HieuHoang
Docker - HieuHoangDocker - HieuHoang
Docker - HieuHoangHieu Hoang
 
Containers in depth – understanding how containers work to better work with c...
Containers in depth – understanding how containers work to better work with c...Containers in depth – understanding how containers work to better work with c...
Containers in depth – understanding how containers work to better work with c...All Things Open
 

What's hot (20)

How to containerize at speed and at scale with Docker Enterprise Edition, mov...
How to containerize at speed and at scale with Docker Enterprise Edition, mov...How to containerize at speed and at scale with Docker Enterprise Edition, mov...
How to containerize at speed and at scale with Docker Enterprise Edition, mov...
 
Docker, how to use it. organize a meeting with IBM products...
Docker, how to use it. organize a meeting with IBM products...Docker, how to use it. organize a meeting with IBM products...
Docker, how to use it. organize a meeting with IBM products...
 
Here Be Dragons: Security Maps of the Container New World
Here Be Dragons: Security Maps of the Container New WorldHere Be Dragons: Security Maps of the Container New World
Here Be Dragons: Security Maps of the Container New World
 
Novell ZENworks Overview and Futures
Novell ZENworks Overview and FuturesNovell ZENworks Overview and Futures
Novell ZENworks Overview and Futures
 
Dockercon EU 2015 Recap
Dockercon EU 2015 RecapDockercon EU 2015 Recap
Dockercon EU 2015 Recap
 
VMware - Snapshot sessions - Deploy and manage tomorrow's applications today
VMware - Snapshot sessions  - Deploy and manage tomorrow's applications todayVMware - Snapshot sessions  - Deploy and manage tomorrow's applications today
VMware - Snapshot sessions - Deploy and manage tomorrow's applications today
 
Containers for Lawyers Richard Fontana
Containers for Lawyers  Richard FontanaContainers for Lawyers  Richard Fontana
Containers for Lawyers Richard Fontana
 
NSS File System Performance, Clustering and Auditing in Novell Open Enterpris...
NSS File System Performance, Clustering and Auditing in Novell Open Enterpris...NSS File System Performance, Clustering and Auditing in Novell Open Enterpris...
NSS File System Performance, Clustering and Auditing in Novell Open Enterpris...
 
Installing and Configuring Novell Conferencing
Installing and Configuring Novell ConferencingInstalling and Configuring Novell Conferencing
Installing and Configuring Novell Conferencing
 
Java Microservices HJUG
Java Microservices HJUGJava Microservices HJUG
Java Microservices HJUG
 
XML Interfaces to the popular Nessus Scanner
XML Interfaces to the popular Nessus ScannerXML Interfaces to the popular Nessus Scanner
XML Interfaces to the popular Nessus Scanner
 
Simplify Your Way To Expert Kubernetes Management
Simplify Your Way To Expert Kubernetes ManagementSimplify Your Way To Expert Kubernetes Management
Simplify Your Way To Expert Kubernetes Management
 
Using Novell Sentinel Log Manager to Monitor Novell Applications
Using Novell Sentinel Log Manager to Monitor Novell ApplicationsUsing Novell Sentinel Log Manager to Monitor Novell Applications
Using Novell Sentinel Log Manager to Monitor Novell Applications
 
Cloud Ready for Linux on System z Technical White Paper
Cloud Ready for Linux on System z Technical White PaperCloud Ready for Linux on System z Technical White Paper
Cloud Ready for Linux on System z Technical White Paper
 
Web Application Debugging Webinar
Web Application Debugging WebinarWeb Application Debugging Webinar
Web Application Debugging Webinar
 
Migrate from Red Hat to SUSE Linux Enterprise Server
Migrate from Red Hat to SUSE Linux Enterprise ServerMigrate from Red Hat to SUSE Linux Enterprise Server
Migrate from Red Hat to SUSE Linux Enterprise Server
 
Thinking about Jenkins Security
Thinking about Jenkins SecurityThinking about Jenkins Security
Thinking about Jenkins Security
 
From Zero to Hero: Continuous Container Security in 4 Simple Steps
From Zero to Hero: Continuous Container Security in 4 Simple StepsFrom Zero to Hero: Continuous Container Security in 4 Simple Steps
From Zero to Hero: Continuous Container Security in 4 Simple Steps
 
Docker - HieuHoang
Docker - HieuHoangDocker - HieuHoang
Docker - HieuHoang
 
Containers in depth – understanding how containers work to better work with c...
Containers in depth – understanding how containers work to better work with c...Containers in depth – understanding how containers work to better work with c...
Containers in depth – understanding how containers work to better work with c...
 

Similar to Understanding docker ecosystem and vulnerabilities points

Dockers and kubernetes
Dockers and kubernetesDockers and kubernetes
Dockers and kubernetesDr Ganesh Iyer
 
Kubernetes Certification Training Course | Docker and Kubernetes Training
Kubernetes Certification Training Course |  Docker and Kubernetes TrainingKubernetes Certification Training Course |  Docker and Kubernetes Training
Kubernetes Certification Training Course | Docker and Kubernetes Trainingnavyatejavisualpath
 
Docker EE 2.0 Choice, Security & Agility
Docker EE 2.0Choice, Security & AgilityDocker EE 2.0Choice, Security & Agility
Docker EE 2.0 Choice, Security & AgilityAshnikbiz
 
Centralize and Simplify Secrets Management for Red Hat OpenShift Container En...
Centralize and Simplify Secrets Management for Red Hat OpenShift Container En...Centralize and Simplify Secrets Management for Red Hat OpenShift Container En...
Centralize and Simplify Secrets Management for Red Hat OpenShift Container En...DevOps.com
 
DevOps Training in Hyderabad | DevOps Online Training 11-10.pptx
DevOps Training in Hyderabad | DevOps Online Training     11-10.pptxDevOps Training in Hyderabad | DevOps Online Training     11-10.pptx
DevOps Training in Hyderabad | DevOps Online Training 11-10.pptxTalluriRenuka
 
DevOps Training in Hyderabad | DevOps Online Training 11-10.pptx
DevOps Training in Hyderabad |  DevOps Online Training     11-10.pptxDevOps Training in Hyderabad |  DevOps Online Training     11-10.pptx
DevOps Training in Hyderabad | DevOps Online Training 11-10.pptxTalluriRenuka
 
A curtain-raiser to the container world Docker & Kubernetes
A curtain-raiser to the container world Docker & KubernetesA curtain-raiser to the container world Docker & Kubernetes
A curtain-raiser to the container world Docker & KuberneteszekeLabs Technologies
 
Docker-PPT.pdf for presentation and other
Docker-PPT.pdf for presentation and otherDocker-PPT.pdf for presentation and other
Docker-PPT.pdf for presentation and otheradarsh20cs004
 
Docker & aPaaS: Enterprise Innovation and Trends for 2015
Docker & aPaaS: Enterprise Innovation and Trends for 2015Docker & aPaaS: Enterprise Innovation and Trends for 2015
Docker & aPaaS: Enterprise Innovation and Trends for 2015WaveMaker, Inc.
 
HPC Cloud Burst Using Docker
HPC Cloud Burst Using DockerHPC Cloud Burst Using Docker
HPC Cloud Burst Using DockerIRJET Journal
 
Building microservices with docker
Building microservices with dockerBuilding microservices with docker
Building microservices with dockerRoman Melnyk
 
Week 8 lecture material
Week 8 lecture materialWeek 8 lecture material
Week 8 lecture materialAnkit Gupta
 
Are Your Containers as Secure as You Think?
Are Your Containers as Secure as You Think?Are Your Containers as Secure as You Think?
Are Your Containers as Secure as You Think?DevOps.com
 
Develop and deploy Kubernetes applications with Docker - IBM Index 2018
Develop and deploy Kubernetes  applications with Docker - IBM Index 2018Develop and deploy Kubernetes  applications with Docker - IBM Index 2018
Develop and deploy Kubernetes applications with Docker - IBM Index 2018Patrick Chanezon
 
Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#Karmanjay Verma
 
Kubernetes solutions
Kubernetes solutionsKubernetes solutions
Kubernetes solutionsEric Cattoir
 
Docker Application to Scientific Computing
Docker Application to Scientific ComputingDocker Application to Scientific Computing
Docker Application to Scientific ComputingPeter Bryzgalov
 

Similar to Understanding docker ecosystem and vulnerabilities points (20)

Dockers and kubernetes
Dockers and kubernetesDockers and kubernetes
Dockers and kubernetes
 
Webinar : Docker in Production
Webinar : Docker in ProductionWebinar : Docker in Production
Webinar : Docker in Production
 
Kubernetes Certification Training Course | Docker and Kubernetes Training
Kubernetes Certification Training Course |  Docker and Kubernetes TrainingKubernetes Certification Training Course |  Docker and Kubernetes Training
Kubernetes Certification Training Course | Docker and Kubernetes Training
 
Docker EE 2.0 Choice, Security & Agility
Docker EE 2.0Choice, Security & AgilityDocker EE 2.0Choice, Security & Agility
Docker EE 2.0 Choice, Security & Agility
 
Centralize and Simplify Secrets Management for Red Hat OpenShift Container En...
Centralize and Simplify Secrets Management for Red Hat OpenShift Container En...Centralize and Simplify Secrets Management for Red Hat OpenShift Container En...
Centralize and Simplify Secrets Management for Red Hat OpenShift Container En...
 
DevOps Training in Hyderabad | DevOps Online Training 11-10.pptx
DevOps Training in Hyderabad | DevOps Online Training     11-10.pptxDevOps Training in Hyderabad | DevOps Online Training     11-10.pptx
DevOps Training in Hyderabad | DevOps Online Training 11-10.pptx
 
DevOps Training in Hyderabad | DevOps Online Training 11-10.pptx
DevOps Training in Hyderabad |  DevOps Online Training     11-10.pptxDevOps Training in Hyderabad |  DevOps Online Training     11-10.pptx
DevOps Training in Hyderabad | DevOps Online Training 11-10.pptx
 
A curtain-raiser to the container world Docker & Kubernetes
A curtain-raiser to the container world Docker & KubernetesA curtain-raiser to the container world Docker & Kubernetes
A curtain-raiser to the container world Docker & Kubernetes
 
Docker-PPT.pdf for presentation and other
Docker-PPT.pdf for presentation and otherDocker-PPT.pdf for presentation and other
Docker-PPT.pdf for presentation and other
 
Docker & aPaaS: Enterprise Innovation and Trends for 2015
Docker & aPaaS: Enterprise Innovation and Trends for 2015Docker & aPaaS: Enterprise Innovation and Trends for 2015
Docker & aPaaS: Enterprise Innovation and Trends for 2015
 
Containerization
ContainerizationContainerization
Containerization
 
What is Docker?
What is Docker?What is Docker?
What is Docker?
 
HPC Cloud Burst Using Docker
HPC Cloud Burst Using DockerHPC Cloud Burst Using Docker
HPC Cloud Burst Using Docker
 
Building microservices with docker
Building microservices with dockerBuilding microservices with docker
Building microservices with docker
 
Week 8 lecture material
Week 8 lecture materialWeek 8 lecture material
Week 8 lecture material
 
Are Your Containers as Secure as You Think?
Are Your Containers as Secure as You Think?Are Your Containers as Secure as You Think?
Are Your Containers as Secure as You Think?
 
Develop and deploy Kubernetes applications with Docker - IBM Index 2018
Develop and deploy Kubernetes  applications with Docker - IBM Index 2018Develop and deploy Kubernetes  applications with Docker - IBM Index 2018
Develop and deploy Kubernetes applications with Docker - IBM Index 2018
 
Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#Microservices, Docker deploy and Microservices source code in C#
Microservices, Docker deploy and Microservices source code in C#
 
Kubernetes solutions
Kubernetes solutionsKubernetes solutions
Kubernetes solutions
 
Docker Application to Scientific Computing
Docker Application to Scientific ComputingDocker Application to Scientific Computing
Docker Application to Scientific Computing
 

More from Abdul Khan

7 Ways To Cyberattack And Hack Azure
7 Ways To Cyberattack And Hack Azure7 Ways To Cyberattack And Hack Azure
7 Ways To Cyberattack And Hack AzureAbdul Khan
 
Guide to security patterns for cloud systems and data security in aws and azure
Guide to security patterns for cloud systems and data security in aws and azureGuide to security patterns for cloud systems and data security in aws and azure
Guide to security patterns for cloud systems and data security in aws and azureAbdul Khan
 
Cloud security comparisons between aws and azure
Cloud security comparisons between aws and azureCloud security comparisons between aws and azure
Cloud security comparisons between aws and azureAbdul Khan
 
Complete Architecture and Development Guide To Windows Communication Foundati...
Complete Architecture and Development Guide To Windows Communication Foundati...Complete Architecture and Development Guide To Windows Communication Foundati...
Complete Architecture and Development Guide To Windows Communication Foundati...Abdul Khan
 
Development workflow guide for building docker apps
Development workflow guide for building docker appsDevelopment workflow guide for building docker apps
Development workflow guide for building docker appsAbdul Khan
 
Development workflow guide for building docker apps
Development workflow guide for building docker appsDevelopment workflow guide for building docker apps
Development workflow guide for building docker appsAbdul Khan
 
How To Manage And Reduce Development Techical Debt
How To Manage And Reduce Development Techical DebtHow To Manage And Reduce Development Techical Debt
How To Manage And Reduce Development Techical DebtAbdul Khan
 

More from Abdul Khan (7)

7 Ways To Cyberattack And Hack Azure
7 Ways To Cyberattack And Hack Azure7 Ways To Cyberattack And Hack Azure
7 Ways To Cyberattack And Hack Azure
 
Guide to security patterns for cloud systems and data security in aws and azure
Guide to security patterns for cloud systems and data security in aws and azureGuide to security patterns for cloud systems and data security in aws and azure
Guide to security patterns for cloud systems and data security in aws and azure
 
Cloud security comparisons between aws and azure
Cloud security comparisons between aws and azureCloud security comparisons between aws and azure
Cloud security comparisons between aws and azure
 
Complete Architecture and Development Guide To Windows Communication Foundati...
Complete Architecture and Development Guide To Windows Communication Foundati...Complete Architecture and Development Guide To Windows Communication Foundati...
Complete Architecture and Development Guide To Windows Communication Foundati...
 
Development workflow guide for building docker apps
Development workflow guide for building docker appsDevelopment workflow guide for building docker apps
Development workflow guide for building docker apps
 
Development workflow guide for building docker apps
Development workflow guide for building docker appsDevelopment workflow guide for building docker apps
Development workflow guide for building docker apps
 
How To Manage And Reduce Development Techical Debt
How To Manage And Reduce Development Techical DebtHow To Manage And Reduce Development Techical Debt
How To Manage And Reduce Development Techical Debt
 

Recently uploaded

Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfAlex Barbosa Coqueiro
 
WordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your BrandWordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your Brandgvaughan
 
Rise of the Machines: Known As Drones...
Rise of the Machines: Known As Drones...Rise of the Machines: Known As Drones...
Rise of the Machines: Known As Drones...Rick Flair
 
The Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and ConsThe Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and ConsPixlogix Infotech
 
What is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdfWhat is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdfMounikaPolabathina
 
From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .Alan Dix
 
Gen AI in Business - Global Trends Report 2024.pdf
Gen AI in Business - Global Trends Report 2024.pdfGen AI in Business - Global Trends Report 2024.pdf
Gen AI in Business - Global Trends Report 2024.pdfAddepto
 
A Journey Into the Emotions of Software Developers
A Journey Into the Emotions of Software DevelopersA Journey Into the Emotions of Software Developers
A Journey Into the Emotions of Software DevelopersNicole Novielli
 
Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!Manik S Magar
 
How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.Curtis Poe
 
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxA Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxLoriGlavin3
 
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxLoriGlavin3
 
SALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICESSALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICESmohitsingh558521
 
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek SchlawackFwdays
 
The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxLoriGlavin3
 
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxThe Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxLoriGlavin3
 
Dev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio WebDev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio WebUiPathCommunity
 
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii SoldatenkoFwdays
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024Lorenzo Miniero
 
Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 365Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 3652toLead Limited
 

Recently uploaded (20)

Unraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdfUnraveling Multimodality with Large Language Models.pdf
Unraveling Multimodality with Large Language Models.pdf
 
WordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your BrandWordPress Websites for Engineers: Elevate Your Brand
WordPress Websites for Engineers: Elevate Your Brand
 
Rise of the Machines: Known As Drones...
Rise of the Machines: Known As Drones...Rise of the Machines: Known As Drones...
Rise of the Machines: Known As Drones...
 
The Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and ConsThe Ultimate Guide to Choosing WordPress Pros and Cons
The Ultimate Guide to Choosing WordPress Pros and Cons
 
What is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdfWhat is DBT - The Ultimate Data Build Tool.pdf
What is DBT - The Ultimate Data Build Tool.pdf
 
From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .From Family Reminiscence to Scholarly Archive .
From Family Reminiscence to Scholarly Archive .
 
Gen AI in Business - Global Trends Report 2024.pdf
Gen AI in Business - Global Trends Report 2024.pdfGen AI in Business - Global Trends Report 2024.pdf
Gen AI in Business - Global Trends Report 2024.pdf
 
A Journey Into the Emotions of Software Developers
A Journey Into the Emotions of Software DevelopersA Journey Into the Emotions of Software Developers
A Journey Into the Emotions of Software Developers
 
Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!Anypoint Exchange: It’s Not Just a Repo!
Anypoint Exchange: It’s Not Just a Repo!
 
How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.How AI, OpenAI, and ChatGPT impact business and software.
How AI, OpenAI, and ChatGPT impact business and software.
 
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptxA Deep Dive on Passkeys: FIDO Paris Seminar.pptx
A Deep Dive on Passkeys: FIDO Paris Seminar.pptx
 
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptxUse of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
Use of FIDO in the Payments and Identity Landscape: FIDO Paris Seminar.pptx
 
SALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICESSALESFORCE EDUCATION CLOUD | FEXLE SERVICES
SALESFORCE EDUCATION CLOUD | FEXLE SERVICES
 
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
"Subclassing and Composition – A Pythonic Tour of Trade-Offs", Hynek Schlawack
 
The State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptxThe State of Passkeys with FIDO Alliance.pptx
The State of Passkeys with FIDO Alliance.pptx
 
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptxThe Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
The Role of FIDO in a Cyber Secure Netherlands: FIDO Paris Seminar.pptx
 
Dev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio WebDev Dives: Streamline document processing with UiPath Studio Web
Dev Dives: Streamline document processing with UiPath Studio Web
 
"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko"Debugging python applications inside k8s environment", Andrii Soldatenko
"Debugging python applications inside k8s environment", Andrii Soldatenko
 
SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024SIP trunking in Janus @ Kamailio World 2024
SIP trunking in Janus @ Kamailio World 2024
 
Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 365Ensuring Technical Readiness For Copilot in Microsoft 365
Ensuring Technical Readiness For Copilot in Microsoft 365
 

Understanding docker ecosystem and vulnerabilities points

  • 1. Understanding Docker Ecosystem And Vulnerabilities Points By Abdul khan
  • 2. Author • Abdul Khan • IT Consultant based in Manchester, UK • Engineering Lead, Executive, Technologist, Architect • IT experience, within the private and public sectors (Retail, Banking, Digital, Insurance, M.O.D., HMRC, Aviation, Telecommunication, Housing Associations, Education, Travel, and Pharmaceutical companies). Excellent architectural and strong DevOps experience with proven-track record of delivering E2E, B2B and B2C solution on regional and global programs. • SME in specializing in providing integration, data migration, digital transformations to the cloud solutions (Azure and AWS) • Wealth of experience in global projects across EMEA, ASPAC and LATAM • Liked in profile https://www.linkedin.com/in/abdul-khan-uk/
  • 3. Accreditations Thank you to my good friend and colleague for reviewing, adding value, sharing their vast experience and knowledge. • Steve Lampton (IT Consultant, Cloud SME) specialising in NetOps, DevOps and SecOps
  • 4. Audience Main Audience • Technical Managers • Architects • Technical Leads and DevOps, NetOps an d SecOps Assumptions • Reader has some knowledge of Docker containerisation, and cloud platforms technologies.
  • 5. Understanding Docker Ecosystem And Vulnerabilities Points
  • 6. Content 1. What is Docker EcoSystem? 2. Containerisation Technology 3. Main Advantages of Docker 4. Docker and Containerization 5. Service Discovery and Global Configuration Stores 6. Service Discovery Responsibilities 7. Scheduling, Cluster Management, and Orchestration 8. Identifying Key Vulnerabilities 9. Understand Docker Ecosystem Vulnerable End Points 10. Images Risks Within Container 11. Register Risks within Containers 12. Orchestrator Risks Within Containers 13. Run-Time Risks Of Containers 14. Hosts Risks Within Containers
  • 7. 1. What is Docker EcoSystem? • Containerization is the process of distributing and deploying applications in a portable and predictable way. This is done by packaging components and their dependencies into standardized, isolated, lightweight process environments called containers. • Many organizations are now interested in designing applications and services that can be easily deployed to distributed systems, allowing the system to scale easily and survive machine and application failures. Docker, a containerization platform developed to simplify and standardize deployment in various environments, was largely instrumental in spurring the adoption of this style of service design and management. • A large amount of software has been created to build on this ecosystem of distributed container management.
  • 8. VM 2. Containerisation Technology Type-1 Hypervisor App Libs Guest OS Hypervisor Hardware VM App Libs Guest OS VM App Libs Guest OS VM App Libs Guest OS Hypervisor Host OS VM App Libs Guest OS VM App Libs Guest OS Hardware VM App Libs Guest OS Docker Daemon Host Libraries VM App Libs Guest OS VM App Libs Guest OS Host OS Hardware Conterinersation is a lightweight alternative to full machine virtualization, that involves encapsulating an application in a container with its own operating environment. Type-2 Hypervisor Containers
  • 9. 3. Main Advantages of Docker • Lightweight resource utilization: instead of virtualizing an entire operating system, containers isolate at the process level and use the host’s kernel. • Portability: all of the dependencies for a containerized application are bundled inside of the container, allowing it to run on any Docker host. • Predictability: The host does not care about what is running inside of the container and the container does not care about which host it is running on. The interfaces are standardized and the interactions are predictable.
  • 10. 4. Docker and Containerization • Docker is the most common containerization software in use today. While other containerizing systems exist, Docker makes container creation and management simple and integrates with many open source projects. • The diagram below shows how containers relate to the host system. Containers isolate individual applications and use operating system resources that have been abstracted by Docker. In detailed view containers can be built by “layering”, with multiple containers sharing underlying layers, decreasing resource usage. App A App B Kernel HOST 1 App B App C OS Layer 2 (B) App C Layer 2 (B) Layer 2 (Shared) Layer 1 (Shared)
  • 11. 5. Service Discovery and Global Configuration Stores (1/2) • Service discovery component strategy is aimed at making container deployments scalable and flexible. • Service discovery allows containers to find out about the environment without administrator intervention. • Service discovery finds connection information for the components and they can register themselves so that other tools know that they are available. • These tools also typically function as globally distributed configuration stores where arbitrary config settings can be set for the services operating in your infrastructure.
  • 12. 5. Service Discovery and Global Configuration Stores 2/2 • The simplified view below shows the flow in which one application registers its connection information with the discovery service system. Once registered, other applications can query the discovery service to find out how to connect to the application Service Discover App A 1 App A 2 3 4 HOST 1 192.XXX.1.2 HOST 1 192.XXX.1.3 Connection Request App A is at 192.XXX.1.2 Where is App A?Register App A 192.XXX.1.2
  • 13. 6. Service Discovery Responsibilities • The key responsibilities of service discovery stores are: • Allowing applications to obtain the data needed to connect with to the services they depend on. • Allowing services to register their connection information for the above purpose. • Providing a globally accessible location to store arbitrary configuration data. • Storing information about cluster members as needed by any cluster management software. • Some popular service discovery tools and related projects are: • etcd : service discovery / globally distributed key-value store • consul : service discovery / globally distributed key-value store • zookeeper: service discovery / globally distributed key-value store • crypt : project to encrypt etcd entries • confd: watches key-value store for changes and triggers reconfiguration of services with new values
  • 14. 7. Scheduling, Cluster Management, and Orchestration • Docker Container orchestration tool (Docker Swam) can package and run the application as container • Docker Swam fits into a cluster Management, A mix docker-compose, swarm, that overlay network and a good service discovery tool such as etcd or consul can be used for managing the cluster of docker containers • Schedulers are responsible for starting containers on the available hosts.
  • 15. 8. Identifying Key Vulnerabilities • Insecurity production system configuration • Vulnerabilities in the image distribution, verification, decompression, storage process • Vulnerabilities inside the images • Vulnerabilities directly linked to Docker or Libcointainer • Vulnerabilities of the Linux kernel. Libcontainer
  • 16. CLIENT Above are the key endpoints throughout this Docker ecosystem that can be breached and can be vulnerable at any given point which may lead to malicious or unintended consequences. 9. Understand Docker Ecosystem Vulnerable End Points (1/2) DOCKER HOST REGISTRY docker_build Container Imagesdocker_build 1 X X Docker Daemon Passing secrets from host to container using environment variables at run time X 4 X 3 Running containers as root Running containers with the privileged flag Unsecured access to the Docker API 2 Insecure image registries X 5 X6 Unsecured access to the Docker host(s) Images
  • 17. • Unsecured access to the Docker API • Users added to the “Docker” group can use all Docker functions that utilize images and containers. • Passing secrets from host to container using environment variables at run time • Secrets can be passed through to the Docker container at run time using the “-e“ flag. These secrets have to be passed through in clear text. Automation scripts should be define with variables. Running containers with the privileged “—privileged” flag provides the container with direct access to host elements such as devices and other pieces of hardware. • Running containers as root • By not declaring a user for each container or using the “-user” flag, container users have access to the same GUID and UID as the host machine, even if the passwords are different. This can lead to the container(s) gaining access to files on the host machine if they are mapped within the container. • Insecure image registries • All containers come from one or more registries. With unsecured access to registries, an attacker can manipulate your images to add code – without your approval or knowledge. Use secure your registries with SSL/TSL, create distinct users, store user(s) and certificate information in a secure vault and regularly rotate credentials. • Unsecured access to the Docker host(s) • All efforts to protect Docker APIs, image registries, All SSH and web page connections to your Docker/orchestration host machine should be monitored and recorded, and all root accounts should be managed, stored and regularly rotated in a secure vault. 9. Understand Docker Ecosystem Vulnerable End Points (2/2)
  • 18. • Image vulnerabilities • Images are effectively static archive files that include all the components used to run a given application, components within an image may be missing critical security updates or are otherwise outdated. A common risk in containerized environments is deployed containers having vulnerabilities because the version of the image used to generate the containers has vulnerabilities. • Image configuration • In addition to software defects, images may also have configuration defects. For example, an 719 image may not have a user defined and thus not take advantage of the defense in depth provided 720 by user namespaces. As another example, an image may include an SSH daemon, which exposes 721 the container to unnecessary network risk. Much like in a traditional server or VM, where a poor 722 configuration can still expose a fully up-to-date system to attack, so too can a poorly configured 723 image increase risk even if all the included components are up-to-date. • Embedded malware • Because images are just collections of files packaged together, malicious files could be included 726 intentionally or inadvertently within them. Such malware would have the same capabilities as 727 any other component within the image and thus could be used to attack other containers or hosts 728 within the environment. A possible source of embedded malware is the use of base layers and 729 other images provided by third parties of which the full provenance is not known. • Embedded secrets • Many applications require secrets to enable secure communication between components. For 732 example, a web application may need a username and password to connect to a backend 733 database. Other examples of embedded secrets include connection strings, SSH private keys, and 734 X.509 private keys. When an app is packaged in a container, these secrets can be embedded 735 directly into the image. However, this practice creates a security risk because anyone with access 736 to the image file can easily parse it to learn these secrets. • Image trust • One of the most common high-risk scenarios in any environment is the execution of untrusted 739 software. The portability and ease of reuse of containers increase the temptation for teams to run 740 images from external sources that may not be well validated or trustworthy. For example, when 741 troubleshooting a problem with a web application, a user may find another version of that 742 application available in an image provided by a third party. Using this externally provided image 743 results in the same types of risks that external software traditionally has, such as introducing 744 malware, leaking data, or including components with vulnerabilities. 10. Images Risks Within Container
  • 19. • Insecure connections to registries • Images often contain sensitive components like an organization’s proprietary software and 748 embedded secrets. If connections to registries are performed over insecure channels, the contents 749 of images are subject to the same confidentiality risks as any other data transmitted in the clear. 750 There is also an increased risk of man-in-the-middle attacks that could intercept network traffic 751 intended for registries and steal developer or administrator credentials, provide fraudulent or 752 outdated images to orchestrators, etc. • Stale images in registries • Because registries are typically the source location for all the images an organization deploys, 755 over time the set of images they store can include many vulnerable, out-of-date versions. While 756 these vulnerable images do not directly pose a threat simply by being stored in the registry, they 757 increase the likelihood of accidental deployment of a known-vulnerable version. • Insufficient authentication and authorization restrictions • Because registries may contain images used to run sensitive or proprietary applications and to 760 access sensitive data, insufficient authentication and authorization requirements can lead to 761intellectual property loss and expose significant technical details about an application to an 762 attacker. Even more critically, because registries are typically trusted as a source of valid, 763 approved software, compromise of a registry can potentially lead to compromise of downstream 764 containers and hosts. 11. Register Risks within Containers
  • 20. • Unbounded administrative access • Historically, many orchestrators were designed with the assumption that all users interacting 768 with them would be administrators and those administrators should have environment-wide 769 control. However, in many cases, a single orchestrator may run many different apps, each 770 managed by different teams, and with different sensitivity levels. If the access provided to users 771 and groups is not scoped to their specific needs, a malicious or careless user could affect or 772 subvert the operation of other containers managed by the orchestrator. • Unauthorized access • Orchestrators often include their own authentication directory, which may be separate from the 775 typical directories already in use within an organization. This can lead to weaker account 776 management practices and ‘orphaned’ accounts in the orchestrator because these systems are less 777 rigorously managed. Because many of these accounts are highly privileged within the 778 orchestrator, compromise of them can lead to systemwide compromise. 779 Another concern regarding unauthorized access is the misuse of credentials, such as an attacker 780 getting access to a password through social engineering or other means, then reusing that 781 password to access the orchestrator. • Poorly separated inter-container network traffic • In most containerized environments, traffic between individual nodes is routed over a virtual 784 overlay network. This overlay network is typically managed by the orchestrator and is often 785 opaque to existing network security and management tools. For example, instead of seeing 786 database queries being sent from a web server container to a database container on another host, 787 traditional network filters would only see encrypted packets flowing between two hosts, with no 788 visibility into the actual container endpoints, nor the traffic being sent. This can create a security 789 ‘blindness’ scenario in which organizations are unable to effectively monitor traffic within their 790 own networks. • Potentially even more critical is the risk of traffic from different applications sharing the same 792 virtual networks. If apps of different sensitivity levels, such as a public-facing web site and an 793 internal treasury management app, are using the same virtual network, sensitive internal apps 794 may be exposed to greater risk from network attack. For example, if the public-facing web site is 795 compromised, attackers may be able to use shared networks to attack the treasury app. • Mixing of workload sensitivity levels • Orchestrators are typically focused primarily on driving the scale and density of workloads. This 798 means that, by default, they can place workloads of differing sensitivity levels on the same host. 799 For example, in a default configuration, an orchestrator may place a container running a public-800 facing web server on the same host as one processing sensitive financial data, simply because 801 that host happens to have the most available resources at the time of deployment. In the case of a 802 critical vulnerability in the web server, this can put the container processing sensitive financial 803 data at significantly greater risk of compromise. • Orchestrator • Many orchestrators exist and each supports a wide variety of configurations. Weak orchestrator 806 configurations can expose the orchestrator and all other container technology components to 807 increased risk. Examples of possible consequences include: 808 • • Unauthorized hosts joining the cluster and running containers 809 • • The compromise of a single cluster host implying compromise of the entire cluster—for 810 example, if the same key pairs used for authentication are shared across all nodes 811 • • Communications between the orchestrator and DevOps personnel, administrators, and 812 hosts being unencrypted and unauthenticated node trust 12. Orchestrator Risks Within Containers
  • 21. 13. Run-Time Risks Of Containers • Vulnerabilities within the runtime software • While relatively uncommon, vulnerabilities within the runtime software are particularly 816 dangerous if they allow ‘container escape’ scenarios in which malicious software can attack 817 resources in other containers and the host OS itself. An attacker may also be able to exploit 818 vulnerabilities to compromise the runtime software itself, and then alter that software so it allows 819 the attacker to access other containers, monitor container-to-container communications, etc. • Unbounded network access from containers • By default in most container runtimes, individual containers are able to access each other and the 822 host OS over the network. If a container is compromised and acting maliciously, allowing this 823 network traffic may expose other resources in the environment to risk. For example, a 824 compromised container may be used to scan the network it is connected to in order to find other 825 weaknesses for an attacker to exploit. This risk is related to that from poorly separated virtual 826 networks, as discussed in Section 3.3.3, but different because it is focused more on flows from 827 containers to any outbound destination, not on app “cross talk” scenarios. 828 • Egress network access is more complex to manage in a containerized environment because so 829 much of the connection is virtualized between containers. Thus, traffic from one container to 830 another may appear simply as encapsulated packets while in motion on the network without an 831 understanding of the ultimate source, destination, or payload. Tools and operational processes 832 that are not container aware are not able to inspect this traffic or determine whether it represents 833 a threat. • Insecure container runtime configurations • Container runtimes typically expose many configurable options to administrators. Setting them 836 improperly can lower the relative security of the system. For example, on Linux container hosts, 837 the set of allowed system calls is often limited by default to only those required for safe 838 operation of containers. If this list is widened, it may expose containers and the host OS to 839 increased risk from a compromised container. Similarly, if a container is run in privileged mode, 840 it has access to all the devices on the host, thus allowing it to essentially act as part of the host 841 OS and impact all other containers running on it. 842 • Another example of an insecure runtime configuration is allowing containers to mount sensitive 843 directories on the host. Containers should rarely make changes to the host OS file system and 844 should almost never make changes to locations like /boot or /etc that control the basic 845 functionality of the host OS. If a compromised container is allowed to make changes to these 846 paths, it could be used to elevate privileges and attack the host itself as well as other containers 847 running on the host. • Application vulnerabilities • Even when organizations are taking the precautious recommended in this guide, containers may 850 still be compromised due to flaws in the apps within them. This is not a problem with containers 851 themselves, but instead is just the manifestation of typical software flaws within a container 852 environment. For example, a containerized web app may be vulnerable to cross-site scripting 853 vulnerabilities, and a database front end container may be subject to Structured Query Language 854 (SQL) injection. When a container is compromised, it can be misused in many ways, such as 855 granting unauthorized access to sensitive information or enabling attacks against other containers 856 or the host OS.
  • 22. 14. Hosts Risks Within Containers • Large attack surface • Every host OS has an attack surface, which is the collection of all ways attackers can attempt to 860 access and exploit the host OS’s vulnerabilities. For example, any network-accessible service 861 provides a potential entry point for attackers, adding to the attack surface. The larger the attack 862 surface is, the better the odds are that an attacker can find and access a vulnerability, leading to a 863 compromise of the host OS and the containers running on top of it. • Shared kernel • Container-specific OSs have a much smaller attack surface than that of general-purpose OSs. For 866 example, they do not contain libraries and package managers that enable a general-purpose OS to 867 directly run database and web server apps. However, although containers provide strong 868 software-level isolation of resources, the use of a shared kernel invariably results in a larger 869 inter-object attack surface than seen with hypervisors, even for container-specific OSs. In other 870 words, the level of isolation provided by container runtimes is not as high as that provided by 871 hypervisors • Host OS component vulnerabilities • All host OSs, even container-specific ones, provide foundational system components—for 874 example, the cryptographic libraries used to authenticate remote connections and the kernel 875 primitives used for general process invocation and management. Like any other software, these 876 components can have vulnerabilities and, because they exist low in the container technology 877 architecture, they can impact all the containers and applications that run on these hosts. • Improper user access rights • Container-specific OSs are typically not optimized to support multiuser scenarios since 880 interactive user logon should be rare. Organizations are exposed to risk when users log on 881 directly to hosts to manage containers, rather than going through an orchestration layer. Direct 882 management enables wide-ranging changes to the system and all containers on it, and can 883 potentially enable a user that only needs to manage a specific app’s containers to impact many 884 others. • Host OS file system tampering • Insecure container configurations can expose host volumes to greater risk of file tampering. For 887 example, if a container is allowed to mount sensitive directories on the host OS, that container 888 can then change files in those directories. These changes could impact the stability and security 889 of the host and all other containers running on it.
  • 23. - END OF DECK By Abdul Khan – https://www.linkedin.com/in/abdul-khan-uk/