12 |
13 | {% include license.html %}
14 | {{ page-title }} - {{ i18nText-siteTitle }}
15 |
16 |
17 | {% include metadata.html %}
18 | {% include resources-inc/head.html %}
19 |
20 |
21 | {%- if page.archived -%}
22 | {% include headers-includes/archive.html %}
23 | {%- endif -%}
24 | {% include skiplinks/skiplinks.html %}
25 | {% include header/header.html %}
26 | {{ content }}
27 | {% include footers/footer.html %}
28 | {% include resources-inc/footer.html %}
29 |
30 |
--------------------------------------------------------------------------------
/SECURITY.md:
--------------------------------------------------------------------------------
1 | ([Français](#signalement-des-problèmes-de-sécurité))
2 |
3 | # Reporting Security Issues
4 |
5 | To report a security issue, email [zztbscybers@tbs-sct.gc.ca](mailto:zztbscybers@tbs-sct.gc.ca) and include the word "SECURITY" in the subject line.
6 |
7 | 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.
8 | ______________________
9 |
10 | ([English](#reporting-security-issues))
11 |
12 | ## Signalement des problèmes de sécurité
13 |
14 | 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.
15 |
16 | L’équipe du SCT enverra une réponse indiquant les prochaines étapes de la gestion de votre rapport. Après la réponse initiale à votre rapport, l’équipe de sécurité vous tiendra au courant des progrès vers une solution et l’annonce complète, et peut demander des informations ou des conseils supplémentaires.
17 |
--------------------------------------------------------------------------------
/LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) Her Majesty the Queen in Right of Canada, as represented by the Treasury Board of Canada Secretariat, 2018
4 |
5 | Permission is hereby granted, free of charge, to any person obtaining a copy
6 | of this software and associated documentation files (the "Software"), to deal
7 | in the Software without restriction, including without limitation the rights
8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 |
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 |
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 |
--------------------------------------------------------------------------------
/link-check.js:
--------------------------------------------------------------------------------
1 | #!/usr/bin/env node
2 |
3 | 'use strict';
4 | import fs from 'fs';
5 | import {sync} from 'glob';
6 | import path from 'path';
7 | import chalk from 'chalk';
8 |
9 | import markdownLinkCheck from 'markdown-link-check';
10 |
11 | const files = sync("**/*.md", {ignore: ["node_modules/**/*.md"]})
12 |
13 | const config = JSON.parse(fs.readFileSync(".markdown-link-check.json"));
14 | config.timeout = '30s'
15 |
16 | files.forEach(function(file) {
17 | const markdown = fs.readFileSync(file).toString();
18 | const opts = Object.assign({}, config);
19 |
20 | opts.baseUrl = path.dirname(path.resolve(file)) + '/';
21 |
22 | markdownLinkCheck(markdown, opts, function (err, results) {
23 | if (err) {
24 | console.error('Error', err);
25 | return;
26 | }
27 |
28 | console.log(chalk.green("Reading: " + file));
29 |
30 | results.forEach(function (result) {
31 | if(result.status === "dead") {
32 | if (result.statusCode == 500) {
33 | console.log(chalk.yellow("Server error on target: " + result.link));
34 | }
35 | else {
36 | process.exitCode = 1
37 | console.log(chalk.red("Dead: " + result.link));
38 | }
39 | }
40 | });
41 | });
42 | });
43 |
--------------------------------------------------------------------------------
/.github/ISSUE_TEMPLATE/feature.md:
--------------------------------------------------------------------------------
1 | ---
2 | name: Feature Request
3 | about: For requesting new features or enhancements.
4 | title: ''
5 | labels: enhancement
6 | assignees: ''
7 |
8 | ---
9 |
10 | ### Problem to solve
11 |
12 |
13 |
14 | ### Intended users
15 |
16 |
17 |
18 | ### Further details
19 |
20 |
21 |
22 | ### Proposal
23 |
24 |
25 |
26 | ### Permissions and Security
27 |
28 |
29 |
30 | ### What does success look like, and how can we measure that?
31 |
32 |
33 |
34 | ### Links / references
35 |
--------------------------------------------------------------------------------
/Gemfile:
--------------------------------------------------------------------------------
1 | source "https://rubygems.org"
2 | # Hello! This is where you manage which Jekyll version is used to run.
3 | # When you want to use a different version, change it below, save the
4 | # file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
5 | #
6 | # bundle exec jekyll serve
7 | #
8 | # This will help ensure the proper Jekyll version is running.
9 | # Happy Jekylling!
10 | #gem "jekyll", "~> 4.3.4"
11 | # This is the default theme for new Jekyll sites. You may change this to anything you like.
12 | #gem "jekyll-theme-minimal"
13 | # If you want to use GitHub Pages, remove the "gem "jekyll"" above and
14 | # uncomment the line below. To upgrade, run `bundle update github-pages`.
15 | gem "github-pages", group: :jekyll_plugins
16 | # If you have any plugins, put them here!
17 | group :jekyll_plugins do
18 | gem "jekyll-feed", "~> 0.12"
19 | gem "jekyll-titles-from-headings", "~> 0.5"
20 | end
21 |
22 | # Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
23 | # and associated library.
24 | platforms :mingw, :x64_mingw, :mswin, :jruby do
25 | gem "tzinfo", ">= 1", "< 3"
26 | gem "tzinfo-data"
27 | end
28 |
29 | # Performance-booster for watching directories on Windows
30 | gem "wdm", "~> 0.2", :platforms => [:mingw, :x64_mingw, :mswin]
31 |
32 | # Lock `http_parser.rb` gem to `v0.6.x` on JRuby builds since newer versions of the gem
33 | # do not have a Java counterpart.
34 | gem "http_parser.rb", "~> 0.6.0", :platforms => [:jruby]
35 |
--------------------------------------------------------------------------------
/CONTRIBUTING.md:
--------------------------------------------------------------------------------
1 | # Contributing
2 |
3 | ([Français](#comment-contribuer))
4 |
5 | ## How to Contribute
6 |
7 | When contributing, post comments and discuss changes you wish to make via Issues.
8 |
9 | Feel free to propose changes by creating Pull Requests. If you don't have write access, editing a file will create a Fork of this project for you to save your proposed changes to. Submitting a change to a file will write it to a new Branch in your Fork, so you can send a Pull Request.
10 |
11 | If this is your first time contributing on GitHub, don't worry! Let us know if you have any questions.
12 |
13 | ### Security
14 |
15 | **Do not post any security issues on the public repository!** See [SECURITY.md](SECURITY.md)
16 |
17 | ______________________
18 |
19 | ## Comment contribuer
20 |
21 | Lorsque vous contribuez, veuillez également publier des commentaires et discuter des modifications que vous souhaitez apporter par l'entremise des enjeux (Issues).
22 |
23 | N'hésitez pas à proposer des modifications en créant des demandes de tirage (Pull Requests). Si vous n'avez pas accès au mode de rédaction, la modification d'un fichier créera une copie (Fork) de ce projet afin que vous puissiez enregistrer les modifications que vous proposez. Le fait de proposer une modification à un fichier l'écrira dans une nouvelle branche dans votre copie (Fork), de sorte que vous puissiez envoyer une demande de tirage (Pull Request).
24 |
25 | Si c'est la première fois que vous contribuez à GitHub, ne vous en faites pas! Faites-nous part de vos questions.
26 |
27 | ### Sécurité
28 |
29 | **Ne publiez aucun problème de sécurité sur le dépôt publique!** Voir [SECURITY.md](SECURITY.md)
30 |
--------------------------------------------------------------------------------
/en/1_Introduction.md:
--------------------------------------------------------------------------------
1 | # 1. Introduction
2 |
3 | ([Back](../README.md))
4 |
5 | > **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).
6 |
7 | ## 1.1 Background
8 |
9 | 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.
10 |
11 | ## 1.2 Document Purpose and Scope
12 |
13 | This document provides guidance to developers and operators when deploying applications and services using containers and microservices. It is based on [GC Cloud Reference Architecture](https://gccollab.ca/file/view/590020/gc-cloud-reference-architecture) (v0.95) and is aligned with the [GC Enterprise Security Architecture Program]().
14 |
15 | ## 1.3 Audience
16 |
17 | 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.
18 |
19 | ## 1.4 Document Overview
20 |
21 | This document is structured as follows:
22 |
23 | > [Section 1](#11-background) identifies this document and its purpose,
24 | >
25 | > [Section 2](./2_Context.md) provides context, including definitions and scope
26 | >
27 | > [Section 3](./3_Threat-Environment.md) introduces the threat environment and common attack vectors in a microservice architecture
28 | >
29 | > [Section 4](./4_Implementation-Recommendations.md) provides implementation recommendations to secure containers and microservices, including the hosts, orchestrators and security brokers; and
30 | >
31 | > [Section 5](./5_Microservice_Security.md) provides additional guidance on securing microservices, including the Kubernetes tenancy, service mesh, and network traffic.
32 | >
33 | > [Section 6](./6_References.md) identifies the applicable references cited in this document.
34 |
--------------------------------------------------------------------------------
/en/3_Threat-Environment.md:
--------------------------------------------------------------------------------
1 | # 3. Threat Environment
2 |
3 | ([Back](../README.md))
4 |
5 | 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:
6 |
7 | | Threat | Description |
8 | | --- | --- |
9 | | **Container Compromise** | An attacker can exploit application vulnerabilities or misconfigurations to gain unauthorized access to a container. Once inside, they may:
Launch application-level attacks like DDoS or XSS against public-facing containers.
Execute malicious code or malware.
Scan the network for vulnerabilities and sensitive data.
Break out of the container to access the host system or other containers.
Consume excessive resources to disrupt other containers.
|
10 | | **Lateral Movement** | Compromised containers can attempt to communicate with other containers or nodes within the cluster to spread the attack. |
11 | | **Data Exfiltration** | Attackers can steal sensitive data from containers, often using techniques like reverse shells or covert channels. |
12 | | **Host Compromise** | If the host system is compromised, an attacker can gain access to all containers running on that host, potentially escalating privileges. |
13 | | **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. |
14 | | **Supply Chain Attacks** | Malicious actors can introduce vulnerabilities into the software supply chain, compromising images, libraries, or dependencies. |
15 |
16 | ## Additional Considerations
17 |
18 | In addition to the threats listed above, organizations should consider the following security aspects when deploying containerized environments:
19 |
20 | | Consideration | Description |
21 | | --- | --- |
22 | | **Image Security** | Ensuring the security of container images, including scanning for vulnerabilities and using trusted registries. |
23 | | **Network Security** | Implementing network segmentation, firewalls, and intrusion detection systems to protect container networks. |
24 | | **Identity and Access Management** | Controlling access to Kubernetes resources and enforcing least privilege principles. |
25 | | **Monitoring and Logging** | Continuously monitoring container environments for suspicious activity and maintaining detailed logs for forensic analysis. |
26 | | **Incident Response Planning** | Developing a robust incident response plan to quickly detect, contain, and remediate security incidents. |
27 | | **Compliance and Auditing** | Ensuring that containerized environments comply with relevant security standards and regulations and conducting regular audits to verify compliance. |
28 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | # Guideline for Secure Application Development Annex A: Secure Containers and Microservices
2 |
3 | ([Français](#gabarit-pour-dépôts-de-code-source-ouvert-du-gouvernement-du-canada))
4 |
5 | *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.
6 |
7 | *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.
8 |
9 | *Microservices* are often deployed in *containers* to take advantage of the benefits of both technologies.
10 |
11 | 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.
12 |
13 | ## Table of Contents
14 |
15 | - [1. Introduction](en/1_Introduction.md)
16 | - [1.1 Background](en/1_Introduction.md/#11-background)
17 | - [1.2 Document Purpose and Scope](en/1_Introduction.md/#12-document-purpose-and-scope)
18 | - [1.3 Audience](en/1_Introduction.md/#13-audience)
19 | - [1.4 Document Overview](en/1_Introduction.md/#14-document-overview)
20 | - [2. Context](en/2_Context.md/#2-context)
21 | - [2.1 Definitions](en/2_Context.md/#21-definitions)
22 | - [2.2 Infrastructure](en/2_Context.md/#22-infrastructure)
23 | - [2.3 Containers](en/2_Context.md/#23-containers)
24 | - [2.4 Container Security](en/2_Context.md/#24-container-security)
25 | - [2.5 Microservices](en/2_Context.md/#25-microservices)
26 | - [2.6 Orchestration](en/2_Context.md/#26-orchestration)
27 | - [2.6.1 Service Mesh](en/2_Context.md/#261-service-mesh)
28 | - [2.7 Functions as a Service](en/2_Context.md/#26-functions-as-a-service)
29 | - [3. Threat Environment](en/3_Threat-Environment.md)
30 | - [4. Implementation Recommendations](en/4_Implementation-Recommendations.md)
31 | - [4.1 Host Recommendations](en/4_Implementation-Recommendations.md/#41-host-recommendations)
32 | - [4.2 Image Builds](en/4_Implementation-Recommendations.md/#42-image-builds)
33 | - [4.3 Container Deployment Security](en/4_Implementation-Recommendations.md/#43-container-deployment-security)
34 | - [4.4 Orchestration - Kubernetes](en/4_Implementation-Recommendations.md/#44-orchestration---kubernetes)
35 | - [5. Additional Microservices and Container Security Guidelines](en/5_Microservice_Security.md)
36 | - [5.1 Securing Platform](en/5_Microservice_Security.md#51-securing-platform)
37 | - [5.2 Securing Container Runtime](en/5_Microservice_Security.md#52-securing-container-runtime)
38 | - [5.3 Securing Traffic](en/5_Microservice_Security.md#53-securing-traffic)
39 | - [5.4 Securing Coding Practices](en/5_Microservice_Security.md#54-secure-coding-practices)
40 | - [5.5 Architecting Your Application for Cloud](en/5_Microservice_Security.md#55-architecting-your-application-for-cloud)
41 | - [5.6 Securing Container Images](en/5_Microservice_Security.md#56-securing-container-images)
42 | - [5.7 Observability](en/5_Microservice_Security.md#57-observability)
43 | - [5.8 Secrets Management](en/5_Microservice_Security.md#58-secrets-management)
44 | - [5.9 Continuous Integration/Continuous Deployment (CI/CD)](en/5_Microservice_Security.md#59-continuous-integrationcontinuous-deployment-cicd)
45 | - [5.10 Infrastructure as Code](en/5_Microservice_Security.md#510-infrastructure-as-code)
46 |
47 | ## List of Figures
48 |
49 | - [Figure 2‑1 Monolithic versus Microservice](en/2_Context.md#figure-2-1)
50 | - [Figure 2‑2 High-level overview of VMs, containers, and serverless](en/2_Context.md#figure-2-2)
51 | - [Figure 2‑3 Shared Responsibility Model with Containers](en/2_Context.md#figure-2-3)
52 | - [Figure 2‑4 Container Technologies](en/2_Context.md#figure-2-4)
53 | - [Figure 2‑5 Microservices Architecture (MSA)](en/2_Context.md#figure-2-5)
54 | - [Figure 5-1 VMs vs Containers](en/5_Microservice_Security.md#figure-5-1)
55 | - [Figure 5-2 Kubernetes Attack Surface](en/5_Microservice_Security.md#figure-5-2)
56 | - [Figure 5-3 RBAC in Kubernetes](en/5_Microservice_Security.md#figure-5-3)
57 | - [Figure 5-4 Service Mesh](en/5_Microservice_Security.md#figure-5-4)
58 | - [Figure 5-5 API Gateway with OPA](en/5_Microservice_Security.md#figure-5-5)
59 | - [Figure 5-6 Securing Container Images](en/5_Microservice_Security.md#figure-5-6)
60 |
61 | ## List of Abbreviations and Acronyms
62 |
63 | | Abbreviation | Definition |
64 | | ------------ | -------------------------------------------------- |
65 | | CaaS | Containers as a service |
66 | | CSP | Cloud Service Provider |
67 | | FaaS | Functions as a service |
68 | | GC | Government of Canada |
69 | | IaaS | Infrastructure as a Service |
70 | | IaC | Infrastructure as code |
71 | | IDS | Intrusion Detection System |
72 | | IT | Information Technology |
73 | | JSON | JavaScript Object Notation |
74 | | JWT | JSON Web Tokens |
75 | | K8s | Kubernetes |
76 | | MSA | Microservices Architecture |
77 | | mTLS | Mutual Transport Layer Security |
78 | | NIST | National Institute of Standard and Technology |
79 | | OAuth | Open Authentication |
80 | | OS | Operating system |
81 | | PaaS | Platform as a Service |
82 | | PBMM | Protected B, Medium Integrity, Medium Availability |
83 | | RBAC | Role-base Access Control |
84 | | SaaS | Software as a Service |
85 | | SSH | Secure Shell |
86 | | TBS | Treasury Board of Canada Secretariat |
87 | | TLS | Transport Layer Security |
88 | | VM | Virtual Machine |
89 |
90 | ### How to Contribute
91 |
92 | See [CONTRIBUTING.md](CONTRIBUTING.md)
93 |
94 | ### License
95 |
96 | Unless otherwise noted, the source code of this project is covered under Crown Copyright, Government of Canada, and is distributed under the [MIT License](LICENSE).
97 |
98 | The Canada wordmark and related graphics associated with this distribution are protected under trademark law and copyright law. No permission is granted to use them outside the parameters of the Government of Canada's corporate identity program. For more information, see [Federal identity requirements](https://www.canada.ca/en/treasury-board-secretariat/topics/government-communications/federal-identity-requirements.html).
99 |
100 | ---
101 |
102 | ## Gabarit pour dépôts de code source ouvert du gouvernement du Canada
103 |
104 | - Quel est ce projet?
105 | - Comment ça marche?
106 | - Qui utilisera ce projet?
107 | - Quel est le but de ce projet?
108 |
109 | ### Comment contribuer
110 |
111 | Voir [CONTRIBUTING.md](CONTRIBUTING.md)
112 |
113 | ### Licence
114 |
115 | Sauf indication contraire, le code source de ce projet est protégé par le droit d'auteur de la Couronne du gouvernement du Canada et distribué sous la [licence MIT](LICENSE).
116 |
117 | Le mot-symbole « Canada » et les éléments graphiques connexes liés à cette distribution sont protégés en vertu des lois portant sur les marques de commerce et le droit d'auteur. Aucune autorisation n'est accordée pour leur utilisation à l'extérieur des paramètres du programme de coordination de l'image de marque du gouvernement du Canada. Pour obtenir davantage de renseignements à ce sujet, veuillez consulter les [Exigences pour l'image de marque](https://www.canada.ca/fr/secretariat-conseil-tresor/sujets/communications-gouvernementales/exigences-image-marque.html).
118 |
--------------------------------------------------------------------------------
/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 | # Contributor Covenant Code of Conduct for the [`project_name`] project
2 |
3 | ([Français](#code-de-conduite-pour-le-projet-nom-du-projet))
4 |
5 | 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
6 |
7 | ## Values and Ethics Code for the Public Sector
8 |
9 | The [Values and Ethics Code for the Public Sector](https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=25049)
10 |
11 | ## Our Pledge
12 |
13 | In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
14 |
15 | ## Our Standards
16 |
17 | Examples of behavior that contributes to creating a positive environment include:
18 |
19 | * Using welcoming and inclusive language
20 | * Being respectful of differing viewpoints and experiences
21 | * Gracefully accepting constructive criticism
22 | * Focusing on what is best for the department
23 | * Showing empathy towards other members
24 |
25 | Examples of unacceptable behavior by participants include:
26 |
27 | * The use of sexualized language or imagery and unwelcome sexual attention or advances
28 | * Trolling, insulting/derogatory comments, and personal or political attacks
29 | * Public or private harassment
30 | * Publishing others' private information, such as a physical or electronic address, without explicit permission
31 | * Other conduct which could reasonably be considered inappropriate in a professional setting
32 |
33 | ## Our Responsibilities
34 |
35 | Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
36 |
37 | Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
38 |
39 | ## Scope
40 |
41 | This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project, members or [`department`].
42 | Examples of representing a project, members or [`department`] include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
43 | Representation of a project may be further defined and clarified by project maintainers.
44 |
45 | ## Enforcement
46 |
47 | Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [`project email`].
48 | All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances.
49 | The project team is obligated to maintain confidentiality with regard to the reporter of an incident.
50 | Further details of specific enforcement policies may be posted separately.
51 |
52 | Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
53 |
54 | ## Attribution [EN]
55 |
56 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
57 | available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)
58 |
59 | [homepage]: https://www.contributor-covenant.org
60 |
61 | This Code of Conduct is also inspired by GDS' `alphagov` [Code of conduct](https://github.com/alphagov/code-of-conduct)
62 |
63 | ---
64 |
65 | # Code de conduite pour le projet [`nom du projet`]
66 |
67 |
68 | ([English](#contributor-covenant-code-of-conduct-for-the-project_name-project))
69 |
70 | 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.
71 |
72 | ## Notre engagement
73 |
74 | Dans le but de favoriser un environnement ouvert et accueillant, nous nous engageons, en tant que collaborateurs et responsables, à faire de la participation à notre projet et à notre communauté une expérience sans harcèlement pour tous, quels que soient leur âge, leur taille, leur handicap, leur origine ethnique, leurs caractéristiques sexuelles, leur identité et expression sexuelles, leur niveau d'expérience, leur éducation, leur statut socio-économique, leur nationalité, leur apparence, leur race, leur religion et leur orientation sexuelle et leur identité.
75 |
76 | ## Nos normes
77 |
78 | Exemples de comportements qui contribuent à créer un environnement positif incluent :
79 |
80 | * Utiliser un langage accueillant et inclusif
81 | * Être respectueux des différents points de vue et expériences
82 | * Accepter gracieusement les critiques constructives
83 | * Se concentrer sur ce qui est le mieux pour la communauté
84 | * Faire preuve d'empathie envers les autres membres de la communauté
85 |
86 | Voici des exemples de comportements inacceptables de la part des participants :
87 |
88 | * L'utilisation d'un langage ou d'images sexualisés et d'une attention sexuelle importunée, ou percées
89 | * Trollage, commentaires insultants ou méprisants, et attaques personnelles ou politiques
90 | * Harcèlement public ou privé
91 | * La publication d'informations privées d'autrui, telles que des informations physiques ou électroniques. adresse, sans autorisation explicite
92 | * Tout autre comportement qui pourrait raisonnablement être considéré comme inapproprié dans le cadre d'une enquête du contexte professionnel
93 |
94 | ## Nos responsabilités
95 |
96 | Les responsables de la mise à jour du projet ont la responsabilité de clarifier les normes d'acceptabilité du et on s'attend à ce qu'ils prennent des mesures correctives appropriées et équitables en cas de comportement inacceptable.
97 |
98 | Les responsables de projet ont le droit et la responsabilité de supprimer, d'éditer ou de rejeter les commentaires, les soumissions (commits), le code, les éditions du wiki, les problèmes et autres contributions qui ne sont pas conformes au présent Code de conduite, ou d'interdire temporairement ou définitivement tout contributeur pour d'autres comportements qu'ils jugent inappropriés, menaçant, offensant ou nuisible.
99 |
100 | ## Portée
101 |
102 | Ce Code de conduite s'applique dans tous les espaces du projet, et il s'applique également lorsque une personne représente le projet ou sa communauté dans les espaces publics.
103 | Des exemples de représentation d'un projet ou d'une collectivité comprennent l'utilisation d'un représentant officiel de la l'adresse électronique du projet, l'affichage par l'entremise d'un compte officiel de médias sociaux ou le fait d'agir à titre intérimaire en tant que représentant désigné lors d'un événement en ligne ou hors ligne.
104 | La représentation d'un projet peut être mieux défini et clarifié par les responsables du projet.
105 |
106 | ## Application des règles
107 |
108 | Les cas de comportement abusif, de harcèlement ou d'autres comportements inacceptables peuvent être rapportés en communiquant avec l'équipe de projet à l'adresse suivante :[`courriel`].
109 | Toutes les plaintes feront l'objet d'un examen et d'une enquête et donneront lieu à une réponse qui est jugée nécessaire et appropriée dans les circonstances.
110 | L'équipe de projet est dans l'obligation de respecter la confidentialité à l'égard du déclarant d'un incident.
111 | De plus amples détails sur les politiques d'application spécifiques peuvent être affichés séparément.
112 |
113 | Les responsables de projet qui ne respectent pas ou n'appliquent pas le Code de conduite en bonne et due formepeuvent faire face à des répercussions temporaires ou permanentes déterminées par d'autres membres de la les membres de la direction du projet.
114 |
115 | ## Attribution [FR]
116 |
117 | Le présent Code de conduite est adapté de la version 1.4 du [Pacte du contributeur][page d'accueil],
118 | disponible à l'adresse [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)
119 |
120 | [page d'accueil]: https://www.contributor-covenant.org
121 |
122 | Le présent Code de conduite s'inspire également du " Code de conduite " du [alphaGov](https://github.com/alphagov/code-of-conduct) de GDS.
123 |
--------------------------------------------------------------------------------
/en/4_Implementation-Recommendations.md:
--------------------------------------------------------------------------------
1 | # 4. Implementation Recommendations
2 |
3 | ([Back](../README.md))
4 |
5 | The following are general recommendations for securing containers and Kubernetes.
6 |
7 | ## 4.1 Host Recommendations
8 |
9 | The following are recommendations for securing the host:
10 |
11 | 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).
12 | 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.
13 |
14 | 3. While the benchmarks are the primary reference, consider these additional security best practices:
15 |
16 | | Best Practice | Description |
17 | | --- | --- |
18 | | **Container Runtime Security** |
Enable security features like [`AppArmor`](https://www.apparmor.net/) or `SELinux` on your containers for additional protection.
|
19 | | **Software Supply Chain Security** |
Implement vulnerability scanning of container images in development, CI/CD pipelines, and production environments.
Use trusted container registries and consider signing your container images.
|
20 | | **Network Security** |
Implement network segmentation, firewalls, and intrusion detection systems (IDS) to protect container networks.
|
21 | | **Least Privilege** |
Enforce the [principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege) by granting containers only the minimum permissions they require to function.
|
22 | | **Monitoring and Logging** |
Continuously monitor your container environment for suspicious activity and maintain detailed logs for forensic analysis.
|
23 |
24 | By embracing established security benchmarks and implementing best practices, you can significantly enhance the security posture of your containerized applications and Kubernetes deployments.
25 |
26 | ## 4.2 Image Builds
27 |
28 | Containers are comprised of layered images specified in a `Dockerfile`, which includes a base OS, libraries, and dependencies. Since vulnerabilities can be introduced at each layer of the image, containers should be as minimal as possible, with all components from trusted sources (provenance).
29 |
30 | This starts by using trusted and optimized images with no (major) CVE vulnerabilities; and using only trusted versions and registries (trusted dependencies, signed images, secure and trusted registries). For some builds (i.e. `FROM golang`), consider a multi-stage build to reduce size, unnecessary libraries, and vulnerabilities.
31 |
32 | Organizations should evolve established processes to better fit containerized application build and deployment.
33 |
34 | A sample of specific image build considerations include:
35 |
36 | | Consideration | Description |
37 | | --- | --- |
38 | | **Hardening** |
Harden the Docker engine by implementing CIS Docker Benchmark flags for improved security.
|
39 | | **Patching Base OS** |
Can secure all containers running on the same host.
|
40 | | **Container-specific Host OS** |
Consider using a container-specific Host OS like [CoreOS](https://fedoraproject.org/coreos/), [RancherOS](https://rancher.com/docs/os/v1.x/en/), etc. for a smaller attack surface and easier management.
|
41 | | **Labels, Tags, (Not LATEST)** |
Use labels and tags to identify the image and version.
Use [semantic versioning](https://semver.org/) (e.g. `v1.0.0`).
Don't use `latest`.
|
42 | | **Cryptographic Signing** |
Use cryptographic signing for image verification.
|
43 | | **Best Practices** |
Follow general `Dockerfile` best practices (such as specifying commands in the same line to reduce layers in image)
|
44 |
45 | ## 4.3 Container Deployment Security
46 |
47 | Container deployment can introduce security risks if not properly managed. To mitigate these risks, organizations should consider the following best practices:
48 |
49 | | Best Practice | Description |
50 | | --- | --- |
51 | | **Use a Container Registry** |
Use a private registry to control access to images.
Use a container registry that supports TLS to encrypt data in transit.
Use IAM to control access to the registry.
|
52 | | **Use Cryptographically Signed Images** |
Use cryptographically signed images to verify the integrity and authenticity of the image.
|
53 | | **Use CI/CD Pipelines** |
automate the build, test, and deployment of containerized applications.
Scan images for vulnerabilities and secrets.
Use automated testing to validate the functionality of the application.
Use infrastructure as code (IaC) to define the configuration of the containerized application.
Use automation tools to deploy containers to the target environment.
Use version control to manage changes to the configuration files.
|
54 | | **Use Secrets Management Tools** |
Use secrets management tools to securely store and manage sensitive information like passwords, API keys, and certificates.
|
55 | | **Use Monitoring and Logging Tools** |
Use monitoring and logging tools to track the performance and security of containerized applications.
|
56 |
57 | ## 4.4 Orchestration - Kubernetes
58 |
59 | Kubernetes is a popular container orchestration tool that automates the deployment, scaling, and management of containerized applications. Kubernetes provides a rich set of features for securing containerized applications.
60 |
61 | The benefits of Kubernetes include:
62 |
63 | | Benefit | Description |
64 | | --- | --- |
65 | | **Scalability** | Can scale applications horizontally and vertically to meet demand. |
66 | | **High Availability** | Can automatically restart failed containers and reschedule them on healthy nodes. |
67 | | **Resource Management** | Can manage resources like CPU and memory to ensure that applications run efficiently. |
68 | | **Service Discovery** | Provides a built-in service discovery mechanism that allows applications to communicate with each other. |
69 | | **Load Balancing** | Can distribute incoming traffic across multiple instances of an application to ensure high availability. |
70 | | **Rolling Updates** | Can perform rolling updates of applications to minimize downtime. |
71 | | **Monitoring and Logging** | Provides built-in monitoring and logging capabilities to track the performance and security of applications. |
72 | | **Security** | Provides a rich set of security features to protect containerized applications. |
73 | | **Portability** | Cloud-agnostic and can run on any cloud provider or on-premises infrastructure. |
74 |
75 | Although Kubernetes provides many benefits, it also introduces new security challenges. The configuration and management of Clusters require careful attention to ensure that they are secure.
76 |
77 | > **Note:** Where possible, it is recommended to use a managed Kubernetes service from a cloud provider, as they often provide additional security features and manage the underlying infrastructure for you.
78 | > This eliminates the need to manage the Control plane and ensures that the cluster is always up to date with the latest security patches.
79 |
80 | When managing your own Cluster, it is important to follow best practices for securing the cluster. Specific flags for hardening Can be found in the [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/). Open source tools to verify configuration and compliance to CIS Benchmark include and [kube-bench](https://github.com/aquasecurity/kube-bench) and [kubsec.io](https://kubesec.io/).
81 |
82 | Regardless of style (Managed or self-managed), high-level recommendations and best practices for securing Kubernetes include:
83 |
84 | | Best Practice | Description |
85 | | --- | --- |
86 | | **TLS Everywhere** |
Components and installation methods may enable local ports over HTTPS and administrators should familiarize themselves with the settings of each component to identify potentially unsecured traffic.
|
87 | | **Identity, Authorization, and Authentication** |
Through role-based access control, applying identity and access management and restricted access to elevated privileges.
Permissions on volumes, networks etc. using role and attribute access control.
Using and securing 'etcd' for storing secrets.
Disable legacy authorization.
Rotate keys.
Specific tools include JSON Web Tokens (JWT) and [SPIFFE](https://spiffe.io/) (Spire).
|
88 | | **TLS Everywhere** |
Components and installation methods may enable local ports over HTTPS and administrators should familiarize themselves with the settings of each component to identify potentially unsecured traffic.
|
89 | | **Kubernetes Secrets** |
Ensures that all sensitive information -- such as passwords, `Open Authorization (OAuth)` tokens and `Secure Shell (SSH)` keys -- are encrypted and made available to each Pod only when they are required for a particular task.
|
90 | | **Logging and Telemetry** |
Includes audit trail and use of application monitoring tools built for cloud-native environments.
|
91 | | **Networking** |
Use network policies to segment communication between containers or pods: for example to specify with whom a pods or endpoints can communicate.
Resources to help implement Kubernetes network policy include:
[AWS - Limit pod traffic with Kubernetes network policies](https://docs.aws.amazon.com/eks/latest/userguide/cni-network-policy.html)
[Azure - Limit pod traffic with Kubernetes network policies](https://docs.microsoft.com/en-us/azure/aks/use-network-policies)
[GCP - Limit pod traffic with Kubernetes network policies](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy)
|
92 |
93 | Further details can be found in [kubernetes.io](kubernetes.io), and [NIST Special Publication 800-190 Application Container Security Guide](https://doi.org/10.6028/NIST.SP.800-190).
94 |
--------------------------------------------------------------------------------
/en/2_Context.md:
--------------------------------------------------------------------------------
1 | # 2. Context
2 |
3 | ([Back](../README.md))
4 |
5 | ## 2.1 Definitions
6 |
7 | Containers and orchestrators support cloud native deployments of distributed systems, often based on microservice architecture as depicted in [Figure 2-1](#figure-2-1).
8 |
9 |
10 |
11 | 
12 | _Figure 2‑1 Monolithic versus Microservice_
13 |
14 | - **Microservices** are loosely-coupled applications written as blocks of functionality interconnected via lightweight communication protocols, such as RESTful API's.
15 |
16 | 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).
17 | - **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.
18 | - **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.
19 | - **Kubernetes** is an open source container cluster orchestrator that automates the deployment, scaling, and management of containerized applications.
20 |
21 |
22 |
23 | 
24 | _Figure 2‑2 High-level overview of VMs, containers, and serverless_
25 |
26 | [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:
27 |
28 | - **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)
29 | - **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.
30 |
31 |
32 |
33 | 
34 | _Figure 2‑3 Shared Responsibility Model with Containers_
35 |
36 | ## 2.2 Infrastructure
37 |
38 | 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**_.
39 |
40 | ## 2.3 Containers
41 |
42 | 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.
43 |
44 |
45 |
46 | 
47 | _Figure 2‑4 Container Technologies_
48 |
49 | As depicted in Figure 2‑4 containers sit on top of a physical or virtualized server and its OS.
50 |
51 | | Benefits | Description |
52 | | --------------------------- | ----------- |
53 | | **Agility** | Containers can be deployed quickly and predictably, regardless of the environment. |
54 | | **Isolation** | Containers are isolated from each other and the host OS. |
55 | | **Portability** | Containers can be moved from one environment to another. |
56 | | **Resource Efficiency** | Containers share the host OS kernel and patches/updates, reducing management burden. |
57 |
58 | ## 2.4 Container Security
59 |
60 | 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.
61 |
62 | 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.
63 |
64 | It is important to note that attackers may target container orchestration services and vulnerabilities can exist in the base OS.
65 |
66 | | Consideration | Description |
67 | | ----- | ----------- |
68 | | **Hardening Docker Engine** | Implement CIS Docker Benchmark flags for improved security.|
69 | | **Patching Base OS** | Patching the base OS can secure all containers running on it. |
70 | | **Container-Specific Host OS** | Consider using CoreOS, RancherOS, etc. for smaller attack surface and easier management.|
71 | | **Immutable Root Filesystems** | Leverage immutable root filesystems for easier rollback and consistent state. |
72 | | **Signing Images** | Use labels, tags, and not LATEST to ensure image integrity. |
73 | | **Dockerfile Best Practices** | Use general Dockerfile best practices to reduce image size and complexity. |
74 | | **Cryptographic Signing** | Use cryptographic signing to ensure image integrity. |
75 |
76 | Container security requires a multi-layered approach, leveraging CIS benchmarks, patching, and container-specific OS features.
77 |
78 | ## 2.5 Microservices
79 |
80 | 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.
81 |
82 | 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.
83 |
84 | 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/):
85 |
86 | | MSA Feature | Description |
87 | | --- | --- |
88 | | **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. |
89 | | **API Aggregation** | Microservices communicate with each other through well-defined APIs. This enables communication between services written in different programming languages. |
90 | | **Flexibility** | Microservices can be easily changed or adapted to new circumstances or requirements. This makes projects more adaptable to future changes. |
91 | | **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. |
92 | | **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. |
93 | | **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. |
94 | | **Realtime Load Balancing** | A load balancer distributes requests across multiple microservices in real-time, ensuring that client requests are handled quickly and efficiently. |
95 | | **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. |
96 | | **Versioning** | Versioning manages changes and updates to services over time. This minimizes disruptions to existing clients and ensures compatibility with the latest technologies. |
97 | | **Availability** | Microservices are designed to be available 24/7 or for the maximum amount of time possible, minimizing downtime. |
98 |
99 | 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).
100 |
101 |
102 |
103 | 
104 | _Figure 2‑5 Microservices Architecture (MSA)_
105 |
106 | ## 2.6 Orchestration and Choreography
107 |
108 | The following is a set of features of container orchestration and choreography:
109 |
110 | | Feature | Description |
111 | | --- | --- |
112 | | **Orchestration** | A central orchestrator directs microservices, dictating their actions and timing. Each microservice functions synchronously, unaware of the broader business process it contributes to. |
113 | | **Choreography** | In choreography, microservices possess an understanding of the encompassing business processes they participate in. |
114 | | **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. |
115 |
116 | ### Challenges
117 |
118 | The proliferation of small services that result from a microservices architecture results in a number of security challenges that must be addressed.
119 |
120 | | Challenge | Description |
121 | | --- | --- |
122 | | **Increased Attack Surface** | Microservices increase the attack surface, amplifying any vulnerabilities in the security solution. |
123 | | **External Communication** | Microservices rely on external communication using a multitude of potentially vulnerable APIs. |
124 | | **Diverse OSs and Programming Languages** | Microservices deployments rely on a wide range of OSs and programming languages, each with unique security vulnerabilities. |
125 | | **Network Traffic** | Microservices result in a lot of network traffic, which may result in poor response times due to bandwidth constraints and increased latency. |
126 |
127 | ### Benefits
128 |
129 | Some upsides of a microservice approach include:
130 |
131 | | Upside | Description |
132 | | --- | --- |
133 | | **Rapid Security Updates** | Security updates to microservices can be deployed more rapidly than for monolithic services with complex code dependencies. |
134 | | **Easier Evaluation** | Microservices are easier to evaluate from a security perspective than monolithic services. |
135 |
136 | ### 2.5.2 Service Mesh
137 |
138 | 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.
139 |
140 | | Feature | Description |
141 | | --- | --- |
142 | | **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. |
143 | | **Service Registry and Discovery** | Service registry and discovery are used to manage the location of services and the ability to discover them. |
144 | | **Debugging, Tracing, Logging** | Debugging, tracing, and logging are used to monitor and troubleshoot microservices. |
145 | | **Metrics Collection** | Metrics collection is used to collect and analyze data on the performance of microservices. |
146 | | **Authentication** | Authentication is used to verify the identity of users and services. |
147 | | **Network Separation** | Network separation is used to separate the network traffic of different services. |
148 |
149 | Functions of a service mesh include:
150 |
151 | - Automatic mutual TLS between services
152 | - Service-level RBAC
153 | - External identity provider integration
154 | - Policy and quota enforcement, dynamic per-request routing
155 | - Deployment strategies such as red/black, canary, dark/mirrored
156 | - Distributed tracing
157 | - Network policy between apps/services, and on ingress/egress
158 |
159 | ## 2.6 Functions as a Service
160 |
161 | Functions as a service (FaaS) sometimes referred to as event-driven architecture or even serverless is a relatively recent architectural principle for serving microservices.
162 |
163 | 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:
164 |
165 | - Security (ensuring integrity of code, IAM polices, monitoring, forensics)
166 | - Build pipelines (CI/CD)
167 | - Administration (patching, deployment)
168 | - Architecture (new architectural constructs)
169 |
170 | The following are some of the key features of FaaS:
171 |
172 | | Feature | Description |
173 | | --- | --- |
174 | | **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. |
175 | | **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. |
176 | | **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). |
177 | | **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. |
178 | | **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. |
179 | | **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.|
180 |
181 | Regardless of deployment method, runtime monitoring is required for:
182 |
183 | - Detection of abnormal behaviour from the baseline, leveraging syscalls, network calls and other available information
184 | - Remediation of a potential threat, for example, via container isolation on a different network, pausing the container, or restarting it
185 | - Forensics to identify the event, based on detailed logs and the containers' image during the event
186 | - Run-time policies and isolation, limiting what kinds of behaviour are allowed in your environment
187 | - Vulnerability and dependency scanning, to ensure that the container is not running with known vulnerabilities
188 |
--------------------------------------------------------------------------------
/en/5_Microservice_Security.md:
--------------------------------------------------------------------------------
1 | # 5. Additional Microservices and Container Security Guidelines
2 |
3 | ([Back](../README.md))
4 |
5 | The following section provides additional guidelines to securing your microservices and containers.
6 |
7 | There is already several guidance documents on secure application development, secure coding practices, and secure deployment practices. This document will focus on the specific security considerations for microservices and containers.
8 |
9 | ## 5.1 Securing Platform
10 |
11 | ### Multi-Tenancy
12 |
13 | Multi-tenancy within a single Kubernetes cluster is one of the key
14 | drivers for digging into the security implications of different
15 | deployment patterns. The most secure approach is to only deploy a single
16 | application per K8s cluster, but this becomes very inefficient in terms
17 | of resource usage and operational maintenance of the utilized
18 | infrastructure.
19 |
20 | Throughout the following sections, we will illustrate different options
21 | for isolating and separating workloads, as well as best practices when
22 | establishing your application architecture.
23 |
24 | To get started, it is worth briefly covering the difference between a
25 | container runtime and traditional VM based workload isolation.
26 |
27 | ### Workload Isolation
28 |
29 | The following table lists the different considerations when it comes to workload isolation in containers and VMs.
30 |
31 | | Consideration | Description |
32 | | --- | --- |
33 | | **Hard Isolation** | Traditional VMs offer strong, "hard" isolation due to their separate kernels.|
34 | | **Soft Isolation** | Containers provide "soft" isolation using mechanisms like Kubernetes namespaces. |
35 |
36 | The most fundamental difference between containers and virtual machines (VMs) is related to the host, or kernel environment in which they run.
37 | Each VM runs its own guest OS and as such, has its own kernel. In contrast, a container shares the underlying operating system's kernel with all of the other containers on that host.
38 |
39 | As a simple illustration, the following diagram shows the components of an application as it relates to either VMs or containers.
40 |
41 |
42 |
43 | 
47 | _Figure 5-1 - VMs vs Containers_
48 |
49 | #### Hard Isolation
50 |
51 | Key points to consider when it comes to hard isolation:
52 |
53 | | Consideration | Description |
54 | | --- | --- |
55 | | **Strong Isolation** | VMs provide strong isolation by running separate guest OS and kernels, offering well-understood security realms.|
56 | | **Resource Sharing** | Containers share the host OS kernel, enabling faster startup, lower memory footprint, and efficient resource usage. |
57 |
58 | #### Soft Isolation
59 |
60 | Key points to consider when it comes to soft isolation:
61 |
62 | | Consideration | Description |
63 | | --- | --- |
64 | | **Namespace** |
Kubernetes namespaces provide basic workload separation through resource quotas and user access boundaries.
|
65 | | **Isolation** |
Namespaces provide a level of isolation, but they are not as strong as VMs.
Namespaces do not isolate workloads on physical hosts; workloads in different namespaces can run on the same host.
|
66 |
67 | #### Attack Surface
68 |
69 | The attack surface of a container is the sum of all the different points where an attacker could potentially exploit the container. The attack surface includes the container image, the container runtime, the host OS, the container network, and the Kubernetes API server.
70 |
71 | Consider security implications of:
72 |
73 | | Consideration | Description |
74 | | --- | --- |
75 | | **Kubernetes Platform Architecture** | nodes, kubelet service, API service, etcd service, control plane. |
76 | | **Workload Organization** | Pods, containers, namespaces. |
77 | | **Ecosystem Services** | ingress, storage, certificate management, service mesh. |
78 |
79 |
80 |
81 | 
87 | _Figure 5-2 - Kubernetes Attack Surface_
88 |
89 | ### Workload Scheduling & Placement
90 |
91 | Containers can have dependencies among themselves, dependencies to nodes, and resource demands, that can also change over time. The resources available on a cluster also vary over time, through shrinking or extending the cluster, or by having it consumed by already placed containers. The way we place containers impacts the availability, performance, and capacity of the distributed systems as well. This section covers the scheduling considerations when a workload is scheduled on a node and how Kubernetes manage it.
92 |
93 | The following table is a list of considerations when it comes to workload scheduling and placement in Kubernetes.
94 |
95 | | Consideration | Description |
96 | | --- | --- |
97 | | **Taints and Tolerations** |
Taints and tolerations are used to control which pods can be scheduled on which nodes.
Use taints and tolerations to prevent pods from running on unsuitable nodes (e.g., user workloads on master nodes).
|
98 | | **Pod Affinity/Anti-Affinity** |
Pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled based on labels on pods that are already running on the node.
|
99 | | **Node Affinity/Anti-Affinity** |
Node affinity and anti-affinity allow you to specific nodes or ensure distribution for high availability.
|
100 | | **Built-in vs Custom** |
Utilize built-in taints or define custom taints based on node conditions like readiness, resource pressure, or schedulability.
|
101 |
102 | ### Role-Based Access Control (RBAC)
103 |
104 | #### Kubernetes Cluster Authorization
105 |
106 | Access controls are implemented on the Kubernetes API layer (`kube-apiserver`). When an API request comes in, the authorization permissions will be checked to see whether the user has access to be able to execute this command.
107 |
108 | | Consideration | Description |
109 | | --- | --- |
110 | | **Role-Based Access Control (RBAC)** |
A method of regulating access to computer or network resources based on the roles of individual users within an organization.
Implement access controls at the Kubernetes API layer to govern user permissions for actions and resources.
|
111 | | **Roles and Binding** |
A role is a set of permissions that define the actions that a user is allowed to perform.
`RoleBindings` grant those permissions to the users.
Utilize Roles and RoleBindings for namespace-specific access, and `ClusterRoles` and `ClusterRoleBindings` for cluster-wide access.
|
112 |
113 |
114 |
115 | 
117 | _Figure 5-3 - RBAC in Kubernetes_
118 |
119 | ### Service Mesh
120 |
121 | A service mesh is a programmable framework that allows you to observe, secure, and connect microservices. It doesn't establish connectivity between microservices, but instead has policies and controls that are applied on top of an existing network to govern how microservices interact. Generally a service mesh is agnostic to the language of the application and can be applied to existing applications usually with little to no code changes.
122 |
123 | Features of a service mesh include:
124 |
125 | | Feature | Description |
126 | | --- | --- |
127 | | **Traffic Management** |
Can control the flow of traffic between services, including routing, load balancing, and retries.
Enhance security through a programmable framework that governs microservice interactions.
|
128 | | **Zero Trust** |
Implement Zero Trust network principles with policy-based security controls.
|
129 | | **Separate Planes** |
Consider service meshes for features such as traffic shaping, resiliency, observability, and secure communication.
|
130 |
131 |
132 |
133 | 
134 | _Figure 5-4 - Service Mesh_
135 |
136 | ### Access Control and Policy Enforcement
137 |
138 | Access control policies evolve as the business requirements change -- tying the access control policies to the micro-service code is a bad practice.
139 |
140 | The following table lists the considerations when it comes to access control and policy enforcement:
141 |
142 | | Consideration | Description |
143 | | --- | --- |
144 | | **Open Policy Agent (OPA)** |
OPA is a general-purpose policy engine that can be used to enforce policies across the Kubernetes ecosystem.
Use OPA to externalize and enforce fine-grained access control policies across the Kubernetes ecosystem.
|
145 | | **Policy Enforcement** |
Define policies for API authorization, workload deployment restrictions, resource tagging, and other compliance controls.
|
146 | | **API Gateway** |
API gateways can be used to enforce policies at the API gateway level.
Integrate OPA with API gateways for policy enforcement at the edge.
|
147 | | **Cloud IAM** |
Use cloud IAM to manage access to cloud resources and services when deploying microservices on cloud platforms.
Use service or machine accounts to authenticate and authorize services to access cloud resources.
|
148 |
149 | Policy enforcement systems could be integrated with API gateways to enforce the policies at the API gateway level. The following figure illustrates the sequence of events that happens when an API gateway intercepts client requests to apply authorization policies using OPA.
150 |
151 |
152 |
153 | 
154 | _Figure 5-5 - API Gateway with OPA_
155 |
156 | ## 5.2 Securing Container Runtime
157 |
158 | In order to run containers securely, we aim to do the following:
159 |
160 | 1. Use least privilege to carry out the task at hand.
161 | 2. Enforce resource allocation
162 | 3. Limit communication between applications, and to and from the outside world, to a defined and deterministic set of connections.
163 |
164 | ### Least-Privilege Security Settings
165 |
166 | Least privilege is a security concept that requires that every module or program in a computer system be granted the least amount of privilege needed to fulfill its function. This helps to reduce the potential attack surface of the system.
167 |
168 | The following table lists the considerations when it comes to least-privilege security settings in containers:
169 |
170 | | Consideration | Description |
171 | | --- | --- |
172 | | **Avoid Root** | Run containers as non-root users unless specific privileges are required (e.g., modifying the host system, binding to privileged ports) |
173 | | **Read-Only Root Filesystem** | Prevent attackers from writing executable files by setting the root filesystem as read-only, unless write access is essential. |
174 | | **Limit Host Volume Mounts** | Restrict the ability to mount sensitive host directories into containers to prevent unintended modifications. |
175 | | **Disable Privileged Access** | Set `privileged` and `allowPrivilegeEscalation` to _**false**_ unless specifically required. |
176 | | **Restrict System Calls** | Use [`seccomp`](https://www.bing.com/ck/a?!&&p=9acbba49cc8936509ee03e13e8b9bf37593a0902f2fe56133188b3acf0f02e3cJmltdHM9MTczMTQ1NjAwMA&ptn=3&ver=2&hsh=4&fclid=048693a4-15f3-6fbd-0106-80d9147f6e25&psq=seccomp&u=a1aHR0cHM6Ly9rdWJlcm5ldGVzLmlvL2RvY3MvdHV0b3JpYWxzL3NlY3VyaXR5L3NlY2NvbXAv&ntb=1) profiles to limit system calls available within containers, minimizing potential attack vectors.|
177 |
178 | ### Resource Usage
179 |
180 | Containers have multiple dimensions at runtime, such as:
181 |
182 | - memory usage,
183 | - CPU usage, and
184 | - other resource consumption dimensions.
185 |
186 | The following table lists the considerations when it comes to resource usage in containers:
187 |
188 | | Consideration | Description |
189 | | --- | --- |
190 | | **Define the Required Resources** | Define and enforce resource requirements (CPU, memory) for each container to ensure predictable resource allocation and prevent resource starvation.|
191 |
192 | ### Network Policies
193 |
194 | The following table lists the considerations when it comes to network policies in containers:
195 |
196 | | Consideration | Description |
197 | | --- | --- |
198 | | **"Layer 3" Network segmentation** | Restrict pod-to-pod communication and external access using network policies to enhance security and implement network segmentation. |
199 | | **Set Limits** | Consider network policy limitations (pod port focus, service port changes, logging capabilities, FQDN support). |
200 | | **Default Allow-All Policy** | By default, Kubernetes has an allow-all policy, and does not restrict the ability for pods to communicate with each other. |
201 |
202 | ## 5.3 Securing Traffic
203 |
204 | Microservices developer should focus on the business functionality of a microservice, and the management of other concerns like security, observability, and resiliency should be handled by specialized components.
205 | The [`API Gateway`](https://microservices.io/patterns/apigateway.html) and [`Service Mesh`](#service-mesh) are two architectural patterns that help us achieve this goal.
206 |
207 | ### North-South Traffic
208 |
209 | North-South traffic indicates any traffic caused by the communication
210 | between the client/consumer applications and the APIs. To secure the
211 | north-south traffic, an API gateway is typically deployed at the edge of
212 | a network.
213 |
214 | | Consideration | Description |
215 | | --- | --- |
216 | | **North-South Traffic (Client-API Communication)** |
Deploy API gateways at the network edge to secure and manage incoming requests to microservices.
Implement authentication and authorization using protocols like OAuth 2.0 to control access to resources.
Consider API gateways for features like rate limiting, request throttling, analytics, and API monetization
|
217 |
218 | ### East-West Traffic
219 |
220 | East-West traffic indicates the inter-micro-service communications.
221 |
222 | Securing this type of traffic has three aspects:
223 |
224 | | Consideration | Description |
225 | | --- | --- |
226 | | **East-West Traffic (Inter-Microservice Communication)** |
Implement mutual TLS (mTLS) to secure communication between microservices.
Use JWT tokens for for request authentication to verify end-user identities and claims.
Leverage [service meshes](#service-mesh) for decoupling security, observability, routing control, and resiliency from microservices implementation.
|
227 |
228 | ### Event-Driven Systems
229 |
230 | Event-driven systems rely on data streams and the propagation of events to trigger actions. These systems are composed of event producers, event consumers, and event brokers.
231 |
232 | The following table lists the considerations when it comes to securing event-driven systems:
233 |
234 | | Consideration | Description |
235 | | --- | --- |
236 | | **Message broker** | Secure event traffic between microservices using message brokers like
[Kafka](https://kafka.apache.org/)
[Google Pub/Sub](https://cloud.google.com/pubsub)
[Azure Service Bus](https://azure.microsoft.com/en-ca/services/service-bus/)
[AWS SNS](https://aws.amazon.com/sns/)
|
237 | | **Transport Layer Security** | Use TLS/mTLS to encrypt data in transit between microservices and the message broker.|
238 | | **Control access** | Use `IAM` to control which microservices are permitted to connect to the message broker and to authenticate the clients connecting to it.|
239 | | **Access Control Lists (ACLs)**| ACLs permit or deny various micro-services performing different types of actions on the message broker resources such as topics and queues. |
240 |
241 | ## 5.4 Secure Coding Practices
242 |
243 | Secure coding practices are a set of guidelines and best practices that help developers write secure code. The Government of Canada provides guidance on secure coding practices in the [Secure Coding Practices Guide - on GCPedia](https://www.gcpedia.gc.ca/gcwiki/images/0/0c/Guidance_for_Secure_Application_Development.pdf), which are base in large part on the [OWASP Top 10](https://owasp.org/Top10/).
244 |
245 | In addition to the `Secure Coding Practices Guide`, the following list should be considered when developing microservices:
246 |
247 | | Consideration | Description |
248 | | --- | --- |
249 | | **Crypto Libraries** |
Don't write your own crypto code! Use well-known and tested libraries.
|
250 | | **Data in Transit** |
Use SSL and OAuth tokens to protect your APIs and the data in transit.
Use mutual TLS (mTLS) for secure communication between microservices.
|
251 | | **Protect Production Branch** |
Only verified commits should be merged into the production branch.
Use _branch protection rules_ to prevent unauthorized changes to the production branch.
|
252 | | **Secrets Management** |
Never hard-code secrets in your code.
Use a secret management tool to store and retrieve secrets.
|
253 | | **Input Validation** |
Always validate input data to prevent injection attacks.
|
254 | | **Error Handling** |
Implement proper error handling to prevent information leakage.
|
255 | | **Logging** |
Implement proper logging to help with debugging and auditing.
|
256 | | **Dependency Management** |
Keep your dependencies up to date to avoid vulnerabilities.
|
257 | | **Secure Configuration** |
Ensure that your configuration is secure and does not expose sensitive information.
|
258 |
259 | ## 5.5 Architecting Your Application for Cloud
260 |
261 | The purpose of this section is to outline aspects of scalable, resilient, and portable microservices to facilitate them being deployed and monitored to the Cloud.
262 |
263 | The following principles are recommended:
264 |
265 | | Principle | Description |
266 | | --- | --- |
267 | | **Single Concern** |
Containers should address a single concern and do it well.
Use patterns like [sidecar](https://learn.microsoft.com/en-us/azure/architecture/patterns/sidecar) and [init-containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) to address multiple concerns.
This promotes reusability and replaceability
|
268 | | **Immutable Container Images** |
Container images should be immutable and not contain any environment-specific configuration.
Separate application code from configuration.
|
269 | | **Self-Contained Image** |
Container images should be self-contained and not rely on external dependencies.
Minimize the attack surface by using minimal images.
|
270 | | **Lifecycle Conformance** |
React to lifecycle events like readiness, liveness, and termination.
|
271 | | **Process Disposability** |
Containers should be stateless and externalize state to a persistent data store.
Minimize startup time by reducing the amount of work done on container startup.
|
272 |
273 | ## 5.6 Securing Container Images
274 |
275 | The following table provides a list of considerations when it comes to securing container images:
276 |
277 | | Consideration | Description |
278 | | --- | --- |
279 | | **Image Signing** |
Use image signing to validate the provenance of the application software running in a deployment.
For self-managed containers use a tool such as [Sigstore](https://github.com/sigstore/cosign), [Notary](https://github.com/notaryproject/notaryproject#the-notary-v2-journey), or [Docker Content Trust](https://docs.docker.com/engine/security/trust/) to store and assure image metadata.
For cloud-hosted images, see your cloud provider's documentation for signing images.
|
280 | | **Software Bill of Materials (SBOM)** |
Include a software bill of materials (SBOM) with your container image to provide transparency into the components and dependencies of the image.
|
281 | | **Scan Images for Vulnerabilities** |
Use a container image scanner to inspect packages and report on known vulnerabilities.
Scan third-party container images as well as the ones built by your organization.
Re-scan images on a regular basis to detect new vulnerabilities.
|
282 | | **Patch Container Image** |
Update the container to use a repaired version of the package, when a vulnerable package is discovered.
Automate the build process through a CI pipeline.
|
283 | | **Container Image Storage** |
Store images in a private registry that is protected by credentials and not exposed to the internet.
Minimize the impact of public images changing by referencing images from a private repository.
|
284 |
285 | The following figure illustrates the system components, activities, and artifacts involved in securing container images.
286 |
287 |
288 |
289 | 
290 | _Figure 5-6 - Securing Container Images_
291 |
292 | ## 5.7 Observability
293 |
294 | Observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs. In the context of microservices, observability is the ability to understand the internal state of the system by observing the outputs of its components. Observability is a key requirement for microservices, as it allows you to monitor, debug, and optimize your services.
295 |
296 | The following table lists the considerations when it comes to observability in microservices:
297 |
298 | | Consideration | Description |
299 | | --- | --- |
300 | | **Health Check and Auto Healing** |
Expose APIs for the runtime environment to observe the container health and act accordingly.
Use _liveness_ and _readiness_ probes to make a service more robust and resilient.
|
301 | | **Logging** |
Write logs to standard output and standard error streams.
Use a separate storage and lifecycle for logs.
|
302 | | **Monitoring and Custom Metrics** |
Use observability metrics to determine if the production deployment is functioning correctly.
Monitor application health, performance, and availability.
|
303 | | **Tracing** |
Use tracing to view the latency encountered on every instrumented application or service.
Implement a trace that represents the life of a request in a distributed system.
|
304 | | **Anomaly Detection** |
Use AI-supported tools to detect anomalies in the system.
Use anomaly detection to identify performance issues and security threats.
|
305 |
306 | ## 5.8 Secrets Management
307 |
308 | Secrets management is a critical component of container security. A secret, in the context of containers, is any information that will put your organization, customer or application at risk if exposed to an unauthorized person or entity. This includes API keys, ssh keys, passwords, etc.
309 |
310 | The following table lists the considerations when it comes to secrets management in microservices:
311 |
312 | | Consideration | Description |
313 | | --- | --- |
314 | | **Secure Storage** |
Store secrets in a secure location that is encrypted at rest.
Use a **secret management tool** to store and retrieve secrets.
|
315 | | **Dynamic Secret Distribution** |
Use dynamic secrets to automate encryption and authentication of keys.
|
316 | | **Access Control** |
Implement multi-level role-based access to secrets.
|
317 | | **Audit** |
Log all access to secrets.
|
318 | | **Secret Rotation** |
Rotate secrets frequently to reduce the risk of compromise.
|
328 |
329 | ## 5.9 Continuous Integration/Continuous Deployment (CI/CD)
330 |
331 | Your CI/CD pipeline plays a pivotal role in securing your microservices. The following table lists the considerations when it comes to CI/CD security:
332 |
333 | | Consideration | Description |
334 | | --- | --- |
335 | | **Code Commit Signing** | Sign your commits to prove that the code you submitted came from you and wasn't altered while you were transferring it. |
336 | | **Use Machine-to-Machine (M2M) Authentication** | Secure access between your CI/CD pipeline and your secret manager, using M2M authentication such as OAuth 2.0. |
337 | | **Integrate Security Testing in Pipeline** | Integrate security testing into your CI/CD pipeline to identify security flaws before they can be exploited.|
338 | | **Code analysis and scanning**| Use static code analysis, dynamic analysis, and third-party dependency scanning to identify vulnerabilities. |
339 |
340 | ## 5.10 Infrastructure as Code (IaC)
341 |
342 | Infrastructure as Code (IaC) is the process of managing and provisioning compute infrastructure through machine-readable definition files rather than physically configuring the hardware or by using interactive configuration tools.
343 |
344 | The following table lists the considerations when it comes to IaC security:
345 |
346 | | Consideration | Description |
347 | | --- | --- |
348 | | **Use IaC Tools** |
Use IaC tools like [Terraform](https://terraform.io/), [OpenTofu](https://opentofu.org/), [Ansible](https://www.ansible.com/), [Azure Resource Manager](https://azure.microsoft.com/en-ca/get-started/azure-portal/resource-manager), [AWS CloudFormation](https://docs.aws.amazon.com/cloudformation/), or [GCP Deployment Manager](https://cloud.google.com/deployment-manager/docs/) to automate the provisioning of infrastructure.
Use IaC tools to define and manage infrastructure in a declarative manner.
|
349 | | **Secure IaC Configuration** |
Secure your IaC configuration files by using version control, access control, and encryption.
Use a secret management tool to store and retrieve secrets.
|
350 | | **Automate Security Compliance** |
Automate security compliance checks in your IaC pipeline to ensure that your infrastructure is secure.