diff --git a/.github/workflows/link-check.yml b/.github/workflows/link-check.yml index 82e3b7b..ba62702 100644 --- a/.github/workflows/link-check.yml +++ b/.github/workflows/link-check.yml @@ -24,17 +24,13 @@ jobs: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v4 - - - uses: actions/cache@v3 + - uses: actions/setup-node@v4 with: - path: ~/.npm - key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} - restore-keys: | - ${{ runner.os }}-node- + node-version: 23 + + - uses: actions/checkout@v4 - name: Install Dependencies - if: steps.cache.outputs.cache-hit != 'true' run: npm ci - name: Run link checks diff --git a/.github/workflows/markdownlint.yml b/.github/workflows/markdownlint.yml index ef26eaf..45fa7b5 100644 --- a/.github/workflows/markdownlint.yml +++ b/.github/workflows/markdownlint.yml @@ -24,17 +24,13 @@ jobs: runs-on: ubuntu-latest steps: - - uses: actions/checkout@v4 - - - uses: actions/cache@v3 + - uses: actions/setup-node@v4 with: - path: ~/.npm - key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} - restore-keys: | - ${{ runner.os }}-node- + node-version: 23 + + - uses: actions/checkout@v4 - name: Install Dependencies - if: steps.cache.outputs.cache-hit != 'true' run: npm ci - name: Run Markdownlint diff --git a/.gitignore b/.gitignore index 2f472d9..51ddaeb 100644 --- a/.gitignore +++ b/.gitignore @@ -1,72 +1,7 @@ -.DS_Store - -# Logs -logs -*.log -npm-debug.log* -yarn-debug.log* -yarn-error.log* - -# Runtime data -pids -*.pid -*.seed -*.pid.lock - -# Directory for instrumented libs generated by jscoverage/JSCover -lib-cov - -# Coverage directory used by tools like istanbul -coverage - -# nyc test coverage -.nyc_output - -# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) -.grunt - -# Bower dependency directory (https://bower.io/) -bower_components - -# node-waf configuration -.lock-wscript - -# Compiled binary addons (https://nodejs.org/api/addons.html) -build/Release - -# Dependency directories -node_modules/ -jspm_packages/ - -# TypeScript v1 declaration files -typings/ - -# Optional npm cache directory -.npm - -# Optional eslint cache -.eslintcache - -# Optional REPL history -.node_repl_history - -# Output of 'npm pack' -*.tgz - -# Yarn Integrity file -.yarn-integrity - -# dotenv environment variables file -.env - -# next.js build output -.next - -# local bundler files -.bundle -Gemfile.lock -vendor - -# local Jekyll files _site +.sass-cache +.jekyll-cache .jekyll-metadata +vendor +node_modules +Gemfile.lock diff --git a/.markdownlint.json b/.markdownlint.json index 5b73e20..1dd8622 100644 --- a/.markdownlint.json +++ b/.markdownlint.json @@ -1,6 +1,6 @@ { "default": true, "MD013": false, - "MD041": false, - "MD045": false + "MD033": false, + "MD041": false } diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index aba07f9..49e6f1f 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,6 +1,6 @@ # Contributor Covenant Code of Conduct for the [`project_name`] project -([Français](#Code-de-conduite-pour-le-projet-nom-du-projet)) +([Français](#code-de-conduite-pour-le-projet-nom-du-projet)) Contributors to repositories hosted in [`project_name`] are expected to follow the Contributor Covenant Code of Conduct, and those working within Government are also expected to follow the Values and Ethics Code for the Public Sector @@ -65,7 +65,7 @@ This Code of Conduct is also inspired by GDS' `alphagov` [Code of conduct](https # Code de conduite pour le projet [`nom du projet`] -([English](#Contributor-Covenant-Code-of-Conduct-for-the-projectname-project)) +([English](#contributor-covenant-code-of-conduct-for-the-project_name-project)) Les contributeurs aux dépôts hébergés dans [`nom du projet`] sont tenus de respecter le Code de conduite du Pacte des contributeurs, et ceux qui travaillent au sein du gouvernement sont également tenus de respecter le Code de valeurs et d'éthique du secteur public. diff --git a/Gemfile b/Gemfile new file mode 100644 index 0000000..8560923 --- /dev/null +++ b/Gemfile @@ -0,0 +1,34 @@ +source "https://rubygems.org" +# Hello! This is where you manage which Jekyll version is used to run. +# When you want to use a different version, change it below, save the +# file and run `bundle install`. Run Jekyll with `bundle exec`, like so: +# +# bundle exec jekyll serve +# +# This will help ensure the proper Jekyll version is running. +# Happy Jekylling! +#gem "jekyll", "~> 4.3.4" +# This is the default theme for new Jekyll sites. You may change this to anything you like. +#gem "jekyll-theme-minimal" +# If you want to use GitHub Pages, remove the "gem "jekyll"" above and +# uncomment the line below. To upgrade, run `bundle update github-pages`. +gem "github-pages", group: :jekyll_plugins +# If you have any plugins, put them here! +group :jekyll_plugins do + gem "jekyll-feed", "~> 0.12" + gem "jekyll-titles-from-headings", "~> 0.5" +end + +# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem +# and associated library. +platforms :mingw, :x64_mingw, :mswin, :jruby do + gem "tzinfo", ">= 1", "< 3" + gem "tzinfo-data" +end + +# Performance-booster for watching directories on Windows +gem "wdm", "~> 0.2", :platforms => [:mingw, :x64_mingw, :mswin] + +# Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem +# do not have a Java counterpart. +gem "http_parser.rb", "~> 0.6.0", :platforms => [:jruby] diff --git a/README.md b/README.md index 17abf0b..5f991a5 100644 --- a/README.md +++ b/README.md @@ -2,9 +2,13 @@ ([Français](#gabarit-pour-dépôts-de-code-source-ouvert-du-gouvernement-du-canada)) -With the introduction of cloud services and the adoption of “continuous deployment” of software services, the movement of applications from one environment to another and within an environment is required to be agile and predictable. Container technology (OS virtualization) enables software to deploy quickly and run predictably when moved from one environment to another. Further, microservices are established when a set of containers work together to compose an application. While this approach improves flexibility and scalability for application development and simplifies functionality, it adds another layer of abstraction that must be secured. +*Microservices* are established when a set of functional components work together to compose an application. While this approach improves flexibility and scalability for application development and simplifies functionality, it adds another layer of abstraction that must be secured. -This guidance provides recommendations to secure containers and microservices when deploying Government of Canada (GC) services. It highlights the controls, configuration and tools to secure GC workloads running in containers and orchestrators and recommendations for compliance verification. +*Container* technology (OS virtualization) enables software to be deployed quickly and run predictably when moved from one environment to another. In modern deployments, containers are often orchestrated by a container orchestration tool, such as Kubernetes (K8s) or a cloud provider, to manage the lifecycle of the containers. + +*Microservices* are often deployed in *containers* to take advantage of the benefits of both technologies. + +This guidance provides recommendations to secure *containers* and *microservices* when deploying Government of Canada (GC) services. It highlights the controls, configuration and tools to secure GC workloads running in *containers* and orchestrators and recommendations for compliance verification. ## Table of Contents @@ -19,14 +23,14 @@ This guidance provides recommendations to secure containers and microservices wh - [2.3 Containers](en/2_Context.md/#23-containers) - [2.4 Container Security](en/2_Context.md/#24-container-security) - [2.5 Microservices](en/2_Context.md/#25-microservices) - - [2.5.1 The Ten Commandments of Microservices](en/2_Context.md/#251-the-ten-commandments-of-microservices) - - [2.5.2 Service Mesh](en/2_Context.md/#252-service-mesh) - - [2.6 Functions as a Service](en/2_Context.md/#26-functions-as-a-service) + - [2.6 Orchestration](en/2_Context.md/#26-orchestration) + - [2.6.1 Service Mesh](en/2_Context.md/#261-service-mesh) + - [2.7 Functions as a Service](en/2_Context.md/#26-functions-as-a-service) - [3. Threat Environment](en/3_Threat-Environment.md) - [4. Implementation Recommendations](en/4_Implementation-Recommendations.md) - [4.1 Host Recommendations](en/4_Implementation-Recommendations.md/#41-host-recommendations) - [4.2 Image Builds](en/4_Implementation-Recommendations.md/#42-image-builds) - - [4.3 Container Security Brokers](en/4_Implementation-Recommendations.md/#43-container-security-brokers) + - [4.3 Container Deployment Security](en/4_Implementation-Recommendations.md/#43-container-deployment-security) - [4.4 Orchestration - Kubernetes](en/4_Implementation-Recommendations.md/#44-orchestration---kubernetes) - [5. Additional Microservices and Container Security Guidelines](en/5_Microservice_Security.md) - [5.1 Securing Platform](en/5_Microservice_Security.md#51-securing-platform) @@ -39,51 +43,49 @@ This guidance provides recommendations to secure containers and microservices wh - [5.8 Secrets Management](en/5_Microservice_Security.md#58-secrets-management) - [5.9 Continuous Integration/Continuous Deployment (CI/CD)](en/5_Microservice_Security.md#59-continuous-integrationcontinuous-deployment-cicd) - [5.10 Infrastructure as Code](en/5_Microservice_Security.md#510-infrastructure-as-code) -- [6. References](en/6_References.md) - -## List of Tables - -- [Table 2‑1 Virtualization and Container Quality Attributes](en/2_Context.md/#23-containers) ## List of Figures -- [Figure 2‑1 Monolithic versus Microservice \[1\]](en/2_Context.md/#21-definitions) -- [Figure 2‑2 High-level overview of VM's, containers, and serverless \[3\]](en/2_Context.md/#21-definitions) -- [Figure 2‑3 Shared Responsibility Model with Containers](en/2_Context.md/#21-definitions) -- [Figure 2‑4 Container Technologies](en/2_Context.md/#23-containers) -- [Figure ‎2‑5 Microservices Architecture (MSA)](en/2_Context.md/#25-microservices) -- [Figure ‎2‑6 Example service mesh (CNCF Project Istio) \[12\]](en/2_Context.md/#252-service-mesh) +- [Figure 2‑1 Monolithic versus Microservice](en/2_Context.md#figure-2-1) +- [Figure 2‑2 High-level overview of VMs, containers, and serverless](en/2_Context.md#figure-2-2) +- [Figure 2‑3 Shared Responsibility Model with Containers](en/2_Context.md#figure-2-3) +- [Figure 2‑4 Container Technologies](en/2_Context.md#figure-2-4) +- [Figure 2‑5 Microservices Architecture (MSA)](en/2_Context.md#figure-2-5) +- [Figure 5-1 VMs vs Containers](en/5_Microservice_Security.md#figure-5-1) +- [Figure 5-2 Kubernetes Attack Surface](en/5_Microservice_Security.md#figure-5-2) +- [Figure 5-3 RBAC in Kubernetes](en/5_Microservice_Security.md#figure-5-3) +- [Figure 5-4 Service Mesh](en/5_Microservice_Security.md#figure-5-4) +- [Figure 5-5 API Gateway with OPA](en/5_Microservice_Security.md#figure-5-5) +- [Figure 5-6 Securing Container Images](en/5_Microservice_Security.md#figure-5-6) ## List of Abbreviations and Acronyms | Abbreviation | Definition | | ------------ | -------------------------------------------------- | -| CIRT | Computer Incident Response Team | -| CONOPS | Concept of Operations | -| CSE | Communications Security Establishment | -| CS EMP | Cyber Security Event Management Plan | +| CaaS | Containers as a service | | CSP | Cloud Service Provider | -| FedRAMP | Federal Risk and Authorization Management Program | +| FaaS | Functions as a service | | GC | Government of Canada | -| GSRM | Government of Canada Strategic Reference Model | | IaaS | Infrastructure as a Service | -| IPC | Information Protection Centre | +| IaC | Infrastructure as code | +| IDS | Intrusion Detection System | | IT | Information Technology | -| ITSG | Information Technology Security Guidance | -| LAN | Local Area Network | +| JSON | JavaScript Object Notation | +| JWT | JSON Web Tokens | +| K8s | Kubernetes | +| MSA | Microservices Architecture | +| mTLS | Mutual Transport Layer Security | | NIST | National Institute of Standard and Technology | -| PAA | Program Alignment Architecture | +| OAuth | Open Authentication | +| OS | Operating system | | PaaS | Platform as a Service | | PBMM | Protected B, Medium Integrity, Medium Availability | -| PIA | Privacy Impact Assessment | -| PoAM | Plan of Actions and Milestones | -| RACI | Responsible, Accountable, Consulted, Informed | +| RBAC | Role-base Access Control | | SaaS | Software as a Service | -| SDLC | System Development Lifecycle | -| SLA | Service Level Agreement | -| SSC | Shared Services Canada | +| SSH | Secure Shell | | TBS | Treasury Board of Canada Secretariat | -| ULL | Unclassified, Low Integrity, Low Availability | +| TLS | Transport Layer Security | +| VM | Virtual Machine | ### How to Contribute diff --git a/SECURITY.md b/SECURITY.md index 985c1f8..5baaff3 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,4 +1,4 @@ -([Français](#sécurité)) +([Français](#signalement-des-problèmes-de-sécurité)) # Reporting Security Issues @@ -7,6 +7,8 @@ To report a security issue, email [zztbscybers@tbs-sct.gc.ca](mailto:zztbscybers The TBS team will send a response indicating the next steps in handling your report. After the initial reply to your report, the security team will keep you informed of the progress towards a fix and full announcement, and may ask for additional information or guidance. ______________________ +([English](#reporting-security-issues)) + ## Signalement des problèmes de sécurité Pour signaler un problème de sécurité, envoyez un courriel à [zztbscybers@tbs-sct.gc.ca](mailto:zztbscybers@tbs-sct.gc.ca) et ajoutez le mot « SÉCURITÉ » à la ligne d’objet. diff --git a/_config.yml b/_config.yml index 26934b8..b930230 100644 --- a/_config.yml +++ b/_config.yml @@ -1,4 +1,5 @@ remote_theme: wet-boew/gcweb-jekyll +title: Guidance on Secure Containers and Microservices global: lang: en defaults: @@ -6,6 +7,7 @@ defaults: path: "" # Ensure it's applied to all pages values: layout: default +markdown: gfm plugins: - jekyll-titles-from-headings titles_from_headings: diff --git a/_layouts/core.html b/_layouts/core.html new file mode 100644 index 0000000..02cedf7 --- /dev/null +++ b/_layouts/core.html @@ -0,0 +1,30 @@ +{%- include variable-core.liquid -%} +{%- capture page-title -%} + {%- if page.title -%} + {{ page.title }} + {%- else -%} + Page untitled + {%- endif -%} +{%- endcapture -%} + + + + +{% include license.html %} +{{ page-title }} - {{ i18nText-siteTitle }} + + +{% include metadata.html %} +{% include resources-inc/head.html %} + + +{%- if page.archived -%} + {% include headers-includes/archive.html %} +{%- endif -%} +{% include skiplinks/skiplinks.html %} +{% include header/header.html %} +{{ content }} +{% include footers/footer.html %} +{% include resources-inc/footer.html %} + + \ No newline at end of file diff --git a/assets/css/style.scss b/assets/css/style.scss new file mode 100644 index 0000000..c5eeb90 --- /dev/null +++ b/assets/css/style.scss @@ -0,0 +1,41 @@ +--- +--- +table { + width: 100%; + border-collapse: collapse; + margin-bottom: 2em; +} + +h1, h2, h3 { + margin: 1em 0 2em 0 !important; +} + +tbody tr:first-child td { + padding-top: 0.8em !important; +} + +th { + border-bottom: solid #ddd .18em; + padding: 0.3em 0.8em 0.3em 0.2em !important; +} + +td { + padding: 0 0.8em 0.6em 0 !important; +} + +td em, td b, td strong { + color: #037A8C; + background-color: #f9f2f4; + border-radius: 0.2em; + padding: 2px 4px; + font-weight: normal; +} + +p { + margin: 1em 0 !important; +} + +img { + display: block; + clear: both; +} \ No newline at end of file diff --git a/en/1_Introduction.md b/en/1_Introduction.md index 381f2a0..04b3af4 100644 --- a/en/1_Introduction.md +++ b/en/1_Introduction.md @@ -2,9 +2,11 @@ ([Back](../README.md)) +> **Note:** Generative artificial intelligence was used in the editing process of this publication in accordance with the FASTER principles outlined in the [Guide on the use of generative artificial intelligence - Canada.ca](https://www.canada.ca/en/government/system/digital-government/digital-government-innovations/responsible-use-ai/guide-use-generative-ai.html#toc-4). + ## 1.1 Background -With the introduction of cloud services and the adoption of "continuous deployment" of software services, the movement of applications from one environment to another (Data Centre \<-\> Public Cloud) and within an environment is required to be agile and predictable. Container technology (OS virtualization) enables software to deploy quickly and run predictably when moved from one environment to another. Further, microservices are established when a set of containers work together to compose an application. While this approach improves flexibility and scalability for application development and simplifies functionality, it adds another layer of abstraction that must be secured. +With the introduction of cloud services and the adoption of "continuous deployment" of software services, the movement of applications from one environment to another (Data Centre ↔ Public Cloud) and within an environment is required to be agile and predictable. Container technology (OS virtualization) enables software to deploy quickly and run predictably when moved from one environment to another. Further, microservices are established when a set of containers work together to compose an application. While this approach improves flexibility and scalability for application development and simplifies functionality, it adds another layer of abstraction that must be secured. ## 1.2 Document Purpose and Scope @@ -12,18 +14,20 @@ This document provides guidance to developers and operators when deploying appli ## 1.3 Audience -This document is to be used by developers, operators, business owners, project managers, system and system security practitioners leveraging containers and microservices to deliver GC services. +This document is to be used by developers, operators, business owners, project managers, system and system security practitioners leveraging containers and microservices to deliver Government of Canada (GC) services. ## 1.4 Document Overview This document is structured as follows: -> Section 1 identifies this document and its purpose, +> [Section 1](#11-background) identifies this document and its purpose, +> +> [Section 2](./2_Context.md) provides context, including definitions and scope > -> Section 2 provides context, including definitions and scope +> [Section 3](./3_Threat-Environment.md) introduces the threat environment and common attack vectors in a microservice architecture > -> Section 3 introduces the threat environment and common attack vectors in a microservice architecture +> [Section 4](./4_Implementation-Recommendations.md) provides implementation recommendations to secure containers and microservices, including the hosts, orchestrators and security brokers; and > -> Section 4 provides implementation recommendations to secure containers and microservices, including the hosts, orchestrators and security brokers; and +> [Section 5](./5_Microservice_Security.md) provides additional guidance on securing microservices, including the Kubernetes tenancy, service mesh, and network traffic. > -> Section 5 identifies the applicable references cited in this document. +> [Section 6](./6_References.md) identifies the applicable references cited in this document. diff --git a/en/2_Context.md b/en/2_Context.md index 11f5986..3820f57 100644 --- a/en/2_Context.md +++ b/en/2_Context.md @@ -4,197 +4,149 @@ ## 2.1 Definitions -Containers and orchestrators support cloud native deployments of distributed systems, often based on microservice architecture as depicted in Figure 2-1. +Containers and orchestrators support cloud native deployments of distributed systems, often based on microservice architecture as depicted in [Figure 2-1](#figure-2-1). -![Figure 2-1](../media/image2.png) -_Figure 2‑1 Monolithic versus Microservice [\[1\]](5_References.md)_ + -- **Microservices** are applications written as blocks of code and interconnected via API's. Based on architectural principles such as [Domain Driven Design (DDD)](https://www.thoughtworks.com/insights/blog/domain-driven-design-services-architecture), [12-factor Apps](https://12factor.net/) and Cloud Native Architecture (Infrastructure as code) microservice applications most often use containers, orchestrators and, more recently, functions as a service (serverless). -- **Containers** are portable environments containing application code, associated libraries and dependencies. Developers use build pipelines to create and deploy containerized applications, test and QA in development environments and ship as services to production using package managers and orchestration tools, such as Kubernetes (both managed and hosted). The primary goal of a container is to provide a standardized set of virtual resources to an application process that are separated from the virtual resources provided to other containers deployed on the same platform. The virtual resources are provided based on container configuration information. Virtual resources can also be shared by groups of containers. This allows a container to be deployed and run on any compatible platform regardless of the underlying operating system. -- **Serverless**, Functions as a service (FaaS) and event-driven architecture all initially referred to a microservice that is run on a CSP compute engine only when invoked, without any consideration for infrastructure (an allocation of machine resources and run duration dependant on invocation policy). Recently, serverless is also being used to describe a managed container service (CaaS), where the user is not responsible for the host environment where their container runs. -- **Kubernetes** is an open source container cluster orchestrator that automates the deployment, scaling and management of containerized applications. -- **Unit of Deployment**: Cloud native applications are often based on a unit of deployment, usually a container, a collection of containers in a kubernetes pod, or an event-driven function. Units of deployment are most often used as a security boundary when implementing policy. Cloud-native applications are generally distributed, elastic and horizontally scalable systems composed of microservices that isolate state in a minimum of stateful components [\[2\]](5_References.md). +![Figure 2-1](../media/image_1.png) +_Figure 2‑1 Monolithic versus Microservice_ -![Virtual Machines, Containers, Serverless Architecture](../media/image3.jpeg) +- **Microservices** are loosely-coupled applications written as blocks of functionality interconnected via lightweight communication protocols, such as RESTful API's. -_Figure 2‑2 [High-level overview of VM's, containers, and serverless](https://www.cloudops.com/2018/02/serverless-computing-hot-or-not-2/) [\[3\]](5_References.md)_ + Based on architectural principles such as [Domain Driven Design (DDD)](https://www.thoughtworks.com/insights/blog/domain-driven-design-services-architecture), [12-factor Apps](https://12factor.net/) and Cloud Native Architecture (Infrastructure as code) microservice applications most often use containers, orchestrators and, more recently, functions as a service (serverless). +- **Containers** are portable computing environments containing pre-built applications, associated libraries and dependencies, and configuration that keeps them independent from the host environment and other containers. +- **Serverless computing**, is a managed container service where the user is not responsible for the host environment where their container run, including the orchestration service. Functions as a service (FaaS) are an example of serverless computing. +- **Kubernetes** is an open source container cluster orchestrator that automates the deployment, scaling, and management of containerized applications. -Figure 2‑3 below depicts the shared responsibility model and concept of managed and hosted cloud services as it relates to containers. This includes: + + +![Virtual Machines, Containers, Serverless Architecture](../media/image_3.png) +_Figure 2‑2 High-level overview of VMs, containers, and serverless_ + +[Figure 2‑3](#figure-2-3) below depicts the shared responsibility model and concept of managed and hosted cloud services as it relates to containers. This includes: - **Managed** implies the control plane of a service is managed by a third party while the data plane is managed by the GC (a managed service such as Azure Kubernetes Service) -- **Hosted** means both the control and data planes are managed by the GC, regardless who manage the infrastructure underneath. For example, deploying Kubernetes on EC2 or on-premise compute. +- **Hosted** means both the control and data planes are managed by the GC, regardless who manages the infrastructure underneath. For example, deploying Kubernetes on EC2 or on-premise servers. -![Figure 2-3](../media/image4.png) + + +![Figure 2-3](../media/image_4.png) _Figure 2‑3 Shared Responsibility Model with Containers_ ## 2.2 Infrastructure -Constrainers, kubernetes and (despite the name) serverless, all run on virtual machines or servers. One of the first steps in container infrastructure security is to harden the hosts on which the container runtime resides, including container engines, kubernetes nodes and pods; and serverless functions; based on current GC security best practices. For managed infrastructure or services, security best practices are partially inherited from cloud service providers with the remaining implemented by the tenant on the resource. +Constrainers, Kubernetes, and serverless computing, all run on virtual machines (VMs) or physical servers. It is important to harden hosts on which the container runtime resides, including container engines, Kubernetes nodes and pods, and serverless functions, based on current GC security best-practices. For managed infrastructure or services, security best-practices are partially inherited from cloud service providers (CSPs) with the remaining implemented by the tenant (GC organization) on the resource, also know as the _**Shared Responsibility Model**_. ## 2.3 Containers -One of the trends outlined in the in the _Enterprise Security Architecture Description Document Annex E -- Application Security (APP)_ [\[4\]](5_References.md) and the _Enterprise Security Architecture Description Document Annex F -- Compute and Storage Services Security (CSS)_ [\[5\]](5_References.md) is the use of containers. +The introduction of cloud services and the adoption of "continuous deployment" of software services has resulted in the movement of applications from one environment to another (Data Centre ↔ Public Cloud) and within an environment was required to be agile and predictable. Container technology (OS virtualization) enables software to deploy quickly and run predictably when moved from one environment to another. -The introduction of cloud services and the adoption of "continuous deployment" of software services has resulted in the movement of applications from one environment to another (Data Centre \<-\> Public Cloud) and within an environment was required to be agile and predictable. Container technology (OS virtualization) enables software to deploy quickly and run predictably when moved from one environment to another. + -![Figure 2-4](../media/image5.jpeg) +![Figure 2-4](../media/image_5.png) _Figure 2‑4 Container Technologies_ -As depicted in Figure 2‑4 containers sit on top of a physical or virtualized server and its OS. Each container shares the host OS kernel and the OS binaries and libraries. Shared components are read-only, with each container able to be written to through a unique mount. This makes containers exceptionally "light" -- containers can be megabytes in size and take just seconds to start, versus minutes for a VM. Table 2‑1 provides a list of quality attributes associated with virtualization and container technologies in a modern data center environment. - -**Table** **2‑1 Virtualization and Container Quality Attributes** - -| **Quality Attributes** | **Virtualization Technology** | **Container Technology** | -| ------------------------- | ------------------------------------- | ----------------------------------------------------- | -| Technology code base size | 2-3 Gigabytes | 20-90 MB's | -| Provisioning | 2-3 minutes | 2-3 seconds | -| Cost | More costly than container technology | Less servers, Less Staff | -| Resource utilization | High | Low | -| DevOps Integration | Difficult, time consuming | Easy | -| Microservices | No advantage | Lightweight containers are suitable for microservices | -| Continuous Deployment | Difficult, time consuming | Containers deploy in seconds | - -The benefits of containers often derive from their speed and lightweight nature; many more containers can be put onto a server than onto a traditional VM. Containers are "shareable" and can be used on a variety of public and private cloud deployments, accelerating DevOps by quickly packaging software services along with their dependencies. Additionally, containers reduce management overhead. Because they share a common operating system, only a single operating system needs care and feeding (bug fixes, patches, etc.). [^1] - -VMs and containers differ on quite a few dimensions, but primarily because containers provide a way to virtualize an OS in order for multiple workloads to run on a single OS instance, whereas with VMs, the hardware is being virtualized to run multiple OS instances. Containers' speed, agility and portability make them yet another tool to help streamline software development and continuous deployment. Distinguishing characteristics include; +As depicted in Figure 2‑4 containers sit on top of a physical or virtualized server and its OS. -- Virtual machines contain a complete operating system and applications. -- Virtual machines use hypervisors to share and manage hardware while containers share the kernel of the host OS to access the hardware. -- Virtual machines have their own kernel and VM's don't use and share the kernel of the host OS, hence VM's are isolated from each other at a deep level. -- Virtual machines residing on the same server can run different operating systems. One VM can run Windows while the VM next door might be running Ubuntu. -- Containers are bound by the host OS, containers on the same server use the same OS. -- Containers are virtualizing the underlying operating system while virtual machines are virtualizing the underlying hardware. - -OS containers are virtual environments that share the kernel of the host operating system but provide user space isolation. For all practical purposes, you can think of OS containers as VMs. You can install, configure and run different applications, libraries, etc., just as you would on any OS. Just as a VM, anything running inside a container can only see resources that have been assigned to that container. - -OS containers are beneficial when a fleet of identical or different flavors of software distributions are required. Containers are created from templates (or images) that determine the structure and contents of the container. It thus allows you to create containers that have identical environments with the same package versions and configurations across all containers. +| Benefits | Description | +| --------------------------- | ----------- | +| **Agility** | Containers can be deployed quickly and predictably, regardless of the environment. | +| **Isolation** | Containers are isolated from each other and the host OS. | +| **Portability** | Containers can be moved from one environment to another. | +| **Resource Efficiency** | Containers share the host OS kernel and patches/updates, reducing management burden. | ## 2.4 Container Security -The introduction of container technology adds another layer of abstraction that must be secured. This begins by configuring the container runtime (i.e. docker engine) with specific flags found in the CIS Docker Benchmark where possible. Running these flags harden the Docker engine and kubernetes Master and Workers (API Server and nodes) based on the NIST Special Publication 800-190 [\[6\]](5_References.md). A matrix has been developed that provides a mapping of controls and container components in the _Security Controls Mapping to Docker and Kubernetes_ [\[7\]](5_References.md) document and provides specific flags as well as open-source tools to assist with compliance. Additionally, DevOps and container orchestration services may be compromised providing opportunities for exploitation. Sophisticated attackers will look to exploit new container services and the tools that support those services. - -The bulk of vulnerabilities exist within the base operating system. Accordingly, a patch to one base O/S can support as many containers as run on that O/S without impacting the containers. This benefit makes vulnerability management significantly easier in container-based deployments. Since containers themselves are often ephemeral, vulnerabilities found in containers (and images) can be mitigated by replacing with a non-vulnerable container. - -The increasing popularity of containers has led to the development of stripped down operating systems that include only the features required to host containers. These include CoreOS, RancherOS, Ubuntu Snappy, VMware Photon, Red Hat Atomic Host, and others. By stripping out unnecessary capabilities, these operating systems have a smaller attack surface and are easier for administrators to maintain and update. - -## 2.5 Microservices - -The decomposition of applications into discrete services began with Service Oriented Architecture (SOA). Often based on legacy monolithic applications, a SOA-based service typically contains a large amount of tightly coupled code with complex dependencies. The size and complexity requires extensive planning, development, and testing to add and deploy new features. This is counter to the concept of agility. Agility is the ability to rapidly develop and deploy new and updated application functions to meet user expectations. Instead of introducing new and updated functionality once or twice a year, many organizations that embrace the DevOps concept are able to deploy daily. For DevOps to be effective, code must decomposed into small, loosely coupled services, each of which can be developed and maintained by a small, tight-knit, group of developers who have a thorough understanding of the code. - -The emerging architectural concept to meet this need is the concept of "microservices" [\[8\]](5_References.md). A system based on the Microservices Architecture (MSA) pattern should be comprised of a set of microservices, each of which has a single responsibility that it should perform it really well. Not all microservices are necessarily small---trying to decompose a service in which the code is both tightly coupled and highly cohesive will do more harm than good---but they each should have a well-defined purpose. To ensure that microservices are as loosely coupled as possible, microservices should not share files or databases -- all sharing of information is via network interfaces. For example, a single microservice may be responsible for a database and receives requests to create, read, update, or delete ("CRUD") data in the database via service requests over the network. - -The traditional concept of an "application" may no longer be applicable in an enterprise environment; instead, microservices may be mixed and matched as needed to meet an organization's specific operational and business requirements. A high-level view of the microservice architecture is shown in Figure ‎2‑5 [\[4\]](5_References.md). - -![Figure 2-5](../media/image6.png) -_Figure ‎2‑5 Microservices Architecture (MSA)_ - -With orchestration, a single orchestrator [^2] "conducts" the microservices, telling them what to do and when. Each microservice responds to requests in a synchronous manner and has no knowledge of the larger business process in which it is participating. With choreography, microservices are aware of the business processes of which they are a part. In an event-driven choreography scheme [\[9\]](5_References.md), when a microservice completes a step in a business process, it posts an asynchronous event. At that point, the next microservice in the business process detects the event, performs its step, and posts another event. Both orchestration and choreography allow steps to be performed in parallel. A decentralized asynchronous approach generally provides looser coupling (which better supports small independent DevOps teams) but has poor or no support for transactions. If a transaction cannot be completed for any reason, the microservices must coordinate with each other to identify and resolve any inconsistencies rather than relying on a centralized, synchronous orchestrator to implement a two-phase commit (2PC) protocol [\[10\]](5_References.md). The end user may also be actively involved in ensuring the consistency and integrity of all services and their associated databases. In practice, an MSA-based system is likely use a combination of choreography and orchestration with one or more microservices performing orchestration functions (i.e., there is no dedicated orchestrator typically present in a traditional SOA). - -As a relatively new concept, there is no single formal definition of a microservice, but industry consensus is that microservices should be stateless and not share access to persistent data stores. Any required state information is exchanged over the network via APIs, and any access to a shared data store should also be via an API call to the microservice responsible for the data stored. - -The proliferation of small services that result from a microservices architecture results in a number of security challenges that must be addressed. These challenges are not fundamentally different from those encountered with a traditional SOA but, as microservices increase the attack surface [^3], any vulnerabilities in the security solution are likely to be amplified. In monolithic and service-oriented architectures, communication among software components is mostly internal. With a microservices architecture, much of this communication is now external using a multitude of potentially vulnerable APIs. Additionally, a microservices deployment is likely to rely on a wider range of operating systems and programming languages, each with its unique set of security vulnerabilities. A final problem is that microservices result in a lot of network traffic and may result in poor response times due to bandwidth constraints and increased latency. - -The upside of a microservice approach is that security updates to microservices can be deployed more rapidly than can occur for monolithic services with complex code dependencies. The latter generally need regressive extensive testing prior to being deployed. As release cycles for services are counted in months, rather than days or weeks for microservices, vulnerabilities can remain in the production environment for considerable periods of time. Being small and highly cohesive, microservices are easier to evaluate from a security perspective than monolithic services. - -### 2.5.1 The Ten Commandments of Microservices - -The following table outlines the ten (10) important guidelines for developing and deploying microservices as defined by the New Stack [\[11\]](5_References.md). - -**1** - **Clean Separation of Stateless and Stateful Services** - -Applications composed of microservices contain both stateless and stateful services. It is important to understand the constraints and limitations of implementing stateful services. If a service relies on the state, it should be separated into a dedicated container that's easily accessible. +CIS Docker Benchmark where possible. Running these flags harden the Docker engine and kubernetes Master and Workers (API Server and nodes) based on the [NIST Special Publication 800-190](https://doi.org/10.6028/NIST.SP.800-190). A matrix has been developed that provides a mapping of controls and container components in the [_Security Controls Mapping to Docker and Kubernetes_](https://www.gcpedia.gc.ca/gcwiki/images/4/48/Security_Controls_Mapping_to_Docker_and_Kubernetes.xlsx) document and provides specific flags as well as open-source tools to assist with compliance. -One of the key advantages of microservices is the ability to scale rapidly. Like other distributed computing architectures, microservices scale better when they are stateless. Within seconds, multiple containers can be launched across multiple hosts. Each container running the service is autonomous and doesn't acknowledge the presence of other services. This makes it possible to precisely scale the required service instead of scaling the VMs. For this pattern to work seamlessly, services should be stateless. Containers are ephemeral and thus, become an ideal choice for microservices. +Container technology adds complexity but also offers security benefits. The CIS Docker Benchmark provides best practices for hardening Docker and Kubernetes while leveraging tools like Security Controls Mapping document. -A microservices-based application may contain stateful services in the form of a relational database management system (RDBMS), NoSQL databases, and file systems. They are packaged as containers with unique attributes. Typically, stateful services offload persistence to the host, which makes it difficult to port containers from one host to another. Technologies, such as Flocker and Docker volume plugins, address this problem by creating a separate persistence layer that's not host-dependent. +It is important to note that attackers may target container orchestration services and vulnerabilities can exist in the base OS. -Typically, stateful services offload persistence to the host or use highly available cloud data stores to provide a persistence layer. Both approaches introduce complications: offloading to the host makes it difficult to port containers from one host to another, and highly available data stores trade consistency for availability, meaning that we have to design for eventual consistency in our data model. +| Consideration | Description | +| ----- | ----------- | +| **Hardening Docker Engine** | Implement CIS Docker Benchmark flags for improved security.| +| **Patching Base OS** | Patching the base OS can secure all containers running on it. | +| **Container-Specific Host OS** | Consider using CoreOS, RancherOS, etc. for smaller attack surface and easier management.| +| **Immutable Root Filesystems** | Leverage immutable root filesystems for easier rollback and consistent state. | +| **Signing Images** | Use labels, tags, and not LATEST to ensure image integrity. | +| **Dockerfile Best Practices** | Use general Dockerfile best practices to reduce image size and complexity. | +| **Cryptographic Signing** | Use cryptographic signing to ensure image integrity. | -Technologies, such as Flocker, help address the host portability problem by creating a separate persistence layer that's not host-dependent. The new cloud datastores, such as Redis, Cassandra, and IBM's Cloudant, maximize availability with minimal delay on consistency. +Container security requires a multi-layered approach, leveraging CIS benchmarks, patching, and container-specific OS features. -As container technologies evolve, it will become easier to tackle the stateful services problem. - -**2** - **Do Not Share Libraries or SDKs** - -The premise of microservices is based on autonomous and fine-grained units of code that do one thing and one thing only. This is closely aligned with the principle of "don't repeat yourself" (DRY), which states that every piece of knowledge must have a single, unambiguous, authoritative representation within a system. - -Every service is a self-contained unit of OS, runtime, framework, third-party libraries and code. When one or more containers rely on the same library, it may be tempting to share the dependencies by centrally configuring them on the host. This model introduces complexities in the long run. It not only it brings host affinity, but also breaks the CI/CD pipeline. Upgrading the library or SDK might end up breaking a service. Each service should be treated entirely independent of others. - -In some scenarios, the commonly used libraries and SDKs can be moved to a dedicated service that can be managed independently, making the service immutable. - -**3** - **Avoid Host Affinity** - -This point was briefly discussed in the context of shared libraries. No assumptions can be made about the host on which the service would run. The host includes the presence of a directory, IP address, port number, a specific distribution and version of the OS, and availability of specific files, libraries and SDKs. - -Each service can be launched on any available host in the cluster that meets the predefined requirements. These requirements are more aligned with the specifications, like the CPU type, storage type, region and availability zone, rather than the software configuration. Services should function independently of the host on which they are deployed. - -In case of stateful services, a dedicated persistent (data volume) container should be considered. - -**4** - **Focus on Services with One Task in Mind** - -Each service must be designed with one task in mind. It may map to one function or a module with a well-defined boundary. This means that there may also be one process per container, but that's not always the case. - -Docker encourages the pattern of running one background process/daemon per container. This makes containers fundamentally different from VMs. While a virtual machine may run the whole stack, a container owns a subset of the stack. For example, when refactoring a LAMP web application for microservices, the web tier with Apache runs in a dedicated container while MySQL moves to another container. - -Microservices are modular, composable and fine-grained units that do one thing and one thing only. - -**5** - **Use a Lightweight Messaging Protocol for Communication** - -There is no hard-and-fast rule on how microservices talk to each other. They can use synchronous or asynchronous channels with any protocol that's platform agnostic. Each service implements a simple request and response mechanism. It's common for microservices to expose well-known HTTP endpoints that can be invoked through REST API calls. - -While HTTP and REST are preferred for synchronous communication, it's becoming increasingly popular to use asynchronous communication between microservices. Many consider the Advanced Message Queuing Protocol (AMQP) standard as the preferred protocol, in this regard. Developing microservices with an asynchronous communication model, while sometimes a little more complex, can have great advantages in terms of minimizing latency and enabling event-driven interactions with applications. - -In the market today, RabbitMQ and Apache Kafka are both commonly used message bus technologies for asynchronous communication between microservices. Also, if the message-passing is done on the same host, then the containers can communicate with each other by way of system calls, as they all share the same kernel. - -**6** - **Design a Well-Defined Entry Point and Exit Point** - -In most cases, microservices are treated like a black box, with less visibility into the actual implementation. With inconsistent entry points and exit points, it will be a nightmare to develop a composed application. - -Similar to the interface definition in COM and CORBA, microservices should expose a well-defined, well-documented contract. This will enable services to seamlessly talk to each other. +## 2.5 Microservices -Even if a microservice is not expected to return an explicit value, it may be important to send the success/failure flag. Implementing a single exit point makes it easy to debug and maintain the code. +For DevOps to be effective, code must decomposed into small, loosely coupled services, each of which can be developed and maintained by a small, tight-knit, group of developers who have a thorough understanding of the code and the domain. -**7** - **Implement a Self-Registration and Discovery Mechanism** +A system based on the Microservices Architecture (MSA) pattern should be comprised of a set of microservices, each of which has a single responsibility that it should perform it reliably, and effectively. -One of the key aspects of microservices is the discovery of a service by the consumer. A central registry is maintained for looking up all available services. +The following is a summary of the _**10 Microservices Design Principles That Every Developer Should Know**_ [found here](https://www.geeksforgeeks.org/10-microservices-design-principles-that-every-developer-should-know/): -Each microservice handles registration within the central service registry. They typically register during the startup and periodically update the registry with current information. When the microservice gets terminated, it needs to be unregistered from the registry. The registry plays a critical role in orchestrating microservices. +| MSA Feature | Description | +| --- | --- | +| **Independent and Autonomous Services** | Each microservice operates independently without relying on other services. This allows each service to be developed, tested, and deployed independently without affecting other parts of the system. | +| **API Aggregation** | Microservices communicate with each other through well-defined APIs. This enables communication between services written in different programming languages. | +| **Flexibility** | Microservices can be easily changed or adapted to new circumstances or requirements. This makes projects more adaptable to future changes. | +| **Scalability** | Microservices can be modified to handle increasing or decreasing traffic, data, and complexity without impacting performance. This can be achieved through techniques such as service partitioning, load balancing, horizontal scaling, and caching. | +| **Constant Monitoring** | Constant monitoring helps to identify and resolve issues quickly in a complex system with multiple microservices. This can be achieved through methods such as logging and metrics, distributed tracing, health checks, and alerting and notifications. | +| **Failure Isolation/Failure Resilience** | Microservices are designed to minimize the impact of failures. This can be achieved through fault-tolerant approaches, such as redundancy, service separation, graceful degradation, and circuit breakers. | +| **Realtime Load Balancing** | A load balancer distributes requests across multiple microservices in real-time, ensuring that client requests are handled quickly and efficiently. | +| **Inclusion of DevSecOps** | DevSecOps promotes communication, collaboration, and automation between development, operations teams, and security teams. This improves the efficiency and effectiveness of the software development process, leading to greater speed, flexibility, and agility. Common DevSecOps tools used with microservices include Docker, Terraform, and Kubernetes. | +| **Versioning** | Versioning manages changes and updates to services over time. This minimizes disruptions to existing clients and ensures compatibility with the latest technologies. | +| **Availability** | Microservices are designed to be available 24/7 or for the maximum amount of time possible, minimizing downtime. | -Consul, etcd and Apache Zookeeper are examples of commonly used registries for microservices. Netflix Eureka is another popular registry that exposes registration APIs to services for registering and unregistering. +The traditional concept of an "application" may no longer be applicable in an enterprise environment; instead, microservices may be mixed and matched as needed to meet an organization's specific operational and business requirements. A high-level view of the microservice architecture is shown in [Figure 2‑5](#figure-2-5). -**8** - **Explicitly Check for Rules and Constraints** + -During deployment, microservices may need to consider special requirements and constraints that impact performance. For example, the in-memory cache service needs to be on the same host as the web API service. The database microservice may have to be deployed on a host with solid-state drive (SSD) storage. The master and slave containers of the database cannot exist on the same host. These constraints are typically identified during the design of the services. +![Figure 2-5](../media/image_6.png) +_Figure 2‑5 Microservices Architecture (MSA)_ -If rules and constraints are not considered by the SysOps team, services may need to raise alerts or log appropriate messages warning about possible implications and side effects. Under extreme conditions, a microservice may have to shut down if the mandatory rule is not respected at deployment +## 2.6 Orchestration and Choreography -**9** - **Prefer Polyglot Over Single Stack** +The following is a set of features of container orchestration and choreography: -One advantage of using microservices is the ability to choose the best of breed OS, languages, runtimes and libraries. For example, the chat microservice can be implemented in Node.js, exposing the websockets; the web API service can be written in Python and Django; the image manipulation service may be in Java; and the web frontend could be implemented with Ruby on Rails. +| Feature | Description | +| --- | --- | +| **Orchestration** | A central orchestrator directs microservices, dictating their actions and timing. Each microservice functions synchronously, unaware of the broader business process it contributes to. | +| **Choreography** | In choreography, microservices possess an understanding of the encompassing business processes they participate in. | +| **Service Mesh** | A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It provides a way to control how different parts of an application share data with one another. | -As long as each service exposes a well-defined interface that's consistent with other services, it can be implemented using the most optimal technology stack. +### Challenges -With Microsoft adding native container support to Windows, it is also possible to mix and match Linux containers with Win32 and .NET containers within the same environment. +The proliferation of small services that result from a microservices architecture results in a number of security challenges that must be addressed. -**10** - **Maintain Independent Revisions and Build Environments** +| Challenge | Description | +| --- | --- | +| **Increased Attack Surface** | Microservices increase the attack surface, amplifying any vulnerabilities in the security solution. | +| **External Communication** | Microservices rely on external communication using a multitude of potentially vulnerable APIs. | +| **Diverse OSs and Programming Languages** | Microservices deployments rely on a wide range of OSs and programming languages, each with unique security vulnerabilities. | +| **Network Traffic** | Microservices result in a lot of network traffic, which may result in poor response times due to bandwidth constraints and increased latency. | -Another benefit of microservices is the ability to code and maintain each service independently. +### Benefits -Though each microservice is part of a large, composite application, from a developer standpoint, it is important to treat each service as an independent unit of code. Each service needs to be versioned and maintained separately in the source code control system. This makes it possible to deploy newer versions of services without disrupting the application. CI/CD pipelines should be designed to take advantage of the independent versioning. +Some upsides of a microservice approach include: -This mechanism makes it possible to implement blue/green testing of each service before rolling out the production version. +| Upside | Description | +| --- | --- | +| **Rapid Security Updates** | Security updates to microservices can be deployed more rapidly than for monolithic services with complex code dependencies. | +| **Easier Evaluation** | Microservices are easier to evaluate from a security perspective than monolithic services. | ### 2.5.2 Service Mesh -Microservices introduce new components, workflow and process into a team, and organizations deploying them soon realize they require new methods and tools for security, observability and management. This most often includes the implementation of a service mesh, with circuit breaking, service registry and discovery; debugging, tracing, logging; metrics collection; authentication; network separation and others. [Istio](https://istio.io/), [Conduit](https://conduit.io/) and/or application platform load balancers (such as [NGINX](https://www.nginx.com/)) implement some or all of these features. - -A recent example with Istio deployed as a 'sidecar' in Kubernetes, supporting policy based networking. - -![BookInfo-v1-Istio (5).png](../media/image7.png) +A service mesh is an infrastructure layer in your application that facilitates communication between services. Service meshes provide capabilities like traffic management, resiliency, policy, security, strong identity, and observability to your workloads. Your application is decoupled from these operational capabilities, while the service mesh moves them out of the application layer and down to the infrastructure layer. -_Figure ‎2‑6 Example service mesh (CNCF Project Istio) [\[12\]](5_References.md)_ +| Feature | Description | +| --- | --- | +| **Circuit Breaking** | Circuit breaking is a design pattern used in modern software development to detect failures and encapsulate the logic of preventing a failure from constantly recurring. | +| **Service Registry and Discovery** | Service registry and discovery are used to manage the location of services and the ability to discover them. | +| **Debugging, Tracing, Logging** | Debugging, tracing, and logging are used to monitor and troubleshoot microservices. | +| **Metrics Collection** | Metrics collection is used to collect and analyze data on the performance of microservices. | +| **Authentication** | Authentication is used to verify the identity of users and services. | +| **Network Separation** | Network separation is used to separate the network traffic of different services. | -Functions of a service mesh: +Functions of a service mesh include: - Automatic mutual TLS between services - Service-level RBAC @@ -206,25 +158,25 @@ Functions of a service mesh: ## 2.6 Functions as a Service -Functions as a service (FaaS) sometimes referred to as event-driven architecture or even serverless is a relatively recent architectural principle found in microservices. Initially FaaS was a piece of code uploaded to run on specific CSP compute engines (i.e. AWS Lambda, Azure Functions, etc.) without any consideration for infrastructure. Serverless has evolved to describe managed containers since the build pipeline does not specify or manage the compute where the container runs. Event-driven architectures sometimes trigger a chain of serverless events, all requiring the application of controls to reduce risk. +Functions as a service (FaaS) sometimes referred to as event-driven architecture or even serverless is a relatively recent architectural principle for serving microservices. -Since an event-driven instance does not exist until invoked, serverless changes IT management, monitoring and requirements in a number of ways: +Since an event-driven compute instance, such as in FaaS, does not exist until invoked, it changes IT management, monitoring, and requirements in a number of ways: -- Security (ensure integrity of code, IAM polices, monitoring, forensics) -- Build pipelines immature (CI/CD) +- Security (ensuring integrity of code, IAM polices, monitoring, forensics) +- Build pipelines (CI/CD) - Administration (patching, deployment) - Architecture (new architectural constructs) -- Lock-in (currently different standards and interoperability between CSP's) - -Security for pure serverless functions are mostly centered on the classification of code and IAM policies and protection for data at rest, since the functions are dormant until executed. Once running, the zoning and access controls can be applied by IAM, CSP policy and third party security brokers. As serverless functions mature, they will be able to inherit controls from the CSP compliance reports. - -Practical considerations for securing serverless functions while invoked include IAM policies, security groups, use of security brokers (third-party and CSP) and authentication, authorization and integrity checking. - -For container-based 'serverless' deploys, container security brokers provide a set of protections for container-as-a-service (CaaS) environments such as Microsoft's Azure Container Instances (ACI), Amazon EC2 Container Service (ECS), Amazon Web Services' Fargate --- through a set of runtime security policies implemented by the CSP or container security brokers. -Protecting serverless functions and containers in a managed container service requires a security perimeter built by resource group, a container frontend and a 'microenforcer' embedded as an additional layer in the image. The microenforcer accompanies the image during shipping to repositories and third-party hosted environment; and protects the containers upon launch. +The following are some of the key features of FaaS: -Overall toolchains for creating and deploying serverless functions are also improving, for example AWS now contains [AWS Serverless Application Repository](https://aws.amazon.com/serverless/serverlessrepo/). Kubernetes always provided a 'serverless' deployment experience and now allows for virtual kubelets for various managed container services. +| Feature | Description | +| --- | --- | +| **Security for Serverless Functions** | Security for serverless functions use centers on code classification, IAM policies, and data-at-rest protection because the functions remain inactive until executed.

Active functions use zoning and access controls implemented through IAM, CSP policy, and external security brokers. As they evolve, serverless functions will receive controls from CSP compliance reports. | +| **Security for Invoked Serverless Functions** | Securing serverless functions involves considerations such as IAM policies, security groups, third-party and CSP-provided security brokers, and authentication, authorization, and integrity checks. | +| **Function-Based Serverless Deployment** | Function-based serverless deployments are fully managed by the CSP. Examples include [Azure Functions](https://azure.microsoft.com/en-us/services/functions), [AWS Lambda](https://aws.amazon.com/lambda), and [Google Cloud Functions](https://cloud.google.com/functions). | +| **Container-Based Serverless Deployments** | Container security brokers offer protections for containers as a service (CaaS) environments. Examples include [Microsoft's Azure Containers Instances (ACI)](https://azure.microsoft.com/en-us/products/container-instances), [AWS Fargate](https://aws.amazon.com/fargate/), and [Google Cloud Run](https://cloud.google.com/run). Protection comes from runtime security policies enforced by either the CSP or container security brokers. | +| **Securing Functions and Containers in Managed Services** | Safeguarding requires a security perimeter constructed using a resource group, a container frontend, and container image cryptographic signing. | +| **Toolchains for Serverless Functions** | New capabilities to simplify the FaaS deployment model are being introduced frequently. Testing frameworks, dependency and vulnerability scanning, deployment, and infrastructure as code (IaC) are all part of these toolchains.| Regardless of deployment method, runtime monitoring is required for: @@ -232,3 +184,4 @@ Regardless of deployment method, runtime monitoring is required for: - Remediation of a potential threat, for example, via container isolation on a different network, pausing the container, or restarting it - Forensics to identify the event, based on detailed logs and the containers' image during the event - Run-time policies and isolation, limiting what kinds of behaviour are allowed in your environment +- Vulnerability and dependency scanning, to ensure that the container is not running with known vulnerabilities diff --git a/en/3_Threat-Environment.md b/en/3_Threat-Environment.md index 410b5d4..bf48688 100644 --- a/en/3_Threat-Environment.md +++ b/en/3_Threat-Environment.md @@ -2,16 +2,26 @@ ([Back](../README.md)) -Cloud native applications based on containers and microservices have vulnerability and attack vectors that need to be mitigated. Container and container orchestrators inherit typical IT vulnerabilities as well as introduce some of their own, especially if containers are started with escalated privileges: +Cloud native applications based on containers and microservices have vulnerability and attack vectors that need to be mitigated. Container and container orchestrators inherit typical IT vulnerabilities as well as introduce some of their own, especially if containers are started with escalated privileges. The following is a list of potential threats to a containerized environment: -- **Container Compromise**: An application misconfiguration or vulnerability enables the attacker to get into a container to start probing for weaknesses in the network, process controls, or file system. Compromised containers may then contain 'typical' IT vulnerabilities: - - Application level DDOS and XSS against public facing containers - - EXEC level download of malware, running a malicious process - - Scan of other internal systems for weaknesses or sensitive data - - Breakout and unauthorized access across containers, hosts or data centers - - Resource hogging to impact or crash other containers -- **Unauthorized connections between pods**: Compromised containers can attempt to connect with other pods on the same or other hosts to launch an attack. -- **Data exfiltration from a pod**: Stealing data from a pod; for example reverse shell in a pod for network tunneling to hide confidential data. -- **Container, Pod or Node compromise**: If the pod host is compromised, a user may escalate to root privilege. An attacker (or developer) can install vulnerable libraries/packages that allow exploits in a container -- **Resource Compromise**: Attempt to compromise Kubernetes resources such as the API Server or kubelets to disrupt the cluster or gain access to secrets, resources, or containers. Potential kubernetes resources include authorization tokens, identities or secrets that could be used to gain unauthorized access. Bad actors could also disrupt running applications and or try to gain control of the underlying resources used to run containers or privilege escalation (via the kubelet, access to etcd or service tokens). -- **Attack Kill Chain**: When a series of malicious activities are used together, often within minutes, to achieve the attackers goal [\[13\]](5_References.md). +| Threat | Description | +| --- | --- | +| **Container Compromise** | An attacker can exploit application vulnerabilities or misconfigurations to gain unauthorized access to a container. Once inside, they may:
| +| **Lateral Movement** | Compromised containers can attempt to communicate with other containers or nodes within the cluster to spread the attack. | +| **Data Exfiltration** | Attackers can steal sensitive data from containers, often using techniques like reverse shells or covert channels. | +| **Host Compromise** | If the host system is compromised, an attacker can gain access to all containers running on that host, potentially escalating privileges. | +| **Kubernetes API Server and Kubelet Attacks** | Attackers may target the Kubernetes API server or kubelets to disrupt the cluster or gain unauthorized access to secrets, resources, or containers. | +| **Supply Chain Attacks** | Malicious actors can introduce vulnerabilities into the software supply chain, compromising images, libraries, or dependencies. | + +## Additional Considerations + +In addition to the threats listed above, organizations should consider the following security aspects when deploying containerized environments: + +| Consideration | Description | +| --- | --- | +| **Image Security** | Ensuring the security of container images, including scanning for vulnerabilities and using trusted registries. | +| **Network Security** | Implementing network segmentation, firewalls, and intrusion detection systems to protect container networks. | +| **Identity and Access Management** | Controlling access to Kubernetes resources and enforcing least privilege principles. | +| **Monitoring and Logging** | Continuously monitoring container environments for suspicious activity and maintaining detailed logs for forensic analysis. | +| **Incident Response Planning** | Developing a robust incident response plan to quickly detect, contain, and remediate security incidents. | +| **Compliance and Auditing** | Ensuring that containerized environments comply with relevant security standards and regulations and conducting regular audits to verify compliance. | diff --git a/en/4_Implementation-Recommendations.md b/en/4_Implementation-Recommendations.md index 9ce1143..2bb566f 100644 --- a/en/4_Implementation-Recommendations.md +++ b/en/4_Implementation-Recommendations.md @@ -8,64 +8,86 @@ The following are general recommendations for securing containers and Kubernetes The following are recommendations for securing the host: -1. Run docker engine with flags per [CIS Docker Community Edition Benchmark](https://www.cisecurity.org/benchmark/docker/): v1.1.0 and NIST Special Publication 800-190 [\[6\]](5_References.md). -2. Check for compliance by running [docker-bench](https://github.com/docker/docker-bench-security) against the host. Flags can also be found in the _Security Controls Mapping to Docker and Kubernetes_ document available on GCpedia. -3. Other high-level recommendations for hosts include: - - Enabling AppArmour or SeLinux on hosts (per host instructions) - - OWASP Version control Package testing - - Vulnerability checking (based on CVE scores, scanned in dev, CI/CD, prod) - - Control parameters (flags) - - Use linux namespaces - - Utilize Seccomp/seccomp-bpf [^4] - - Configure Cgroups - - Use R/O Mounts - - Update host patches - - Run CIS Benchmark security tests [\[14\]](5_References.md) +1. Run docker engine with flags per [CIS Docker Community Edition Benchmark](https://www.cisecurity.org/benchmark/docker/) and [NIST Special Publication 800-190](https://doi.org/10.6028/NIST.SP.800-190). +2. Check for compliance by running tools like [docker-bench](https://github.com/docker/docker-bench-security) against the host. Recommended flags and settings can also be found in the [_Security Controls Mapping to Docker and Kubernetes_](https://www.gcpedia.gc.ca/gcwiki/images/4/48/Security_Controls_Mapping_to_Docker_and_Kubernetes.xlsx) document available on GCpedia. + +3. While the benchmarks are the primary reference, consider these additional security best practices: + +| Best Practice | Description | +| --- | --- | +| **Container Runtime Security** | | +| **Software Supply Chain Security** | | +| **Network Security** |