├── .github └── workflows │ └── main.yml ├── .gitignore ├── CODE_OF_CONDUCT.md ├── LICENSE.TXT ├── README.md ├── SECURITY.md ├── SUPPORT.md ├── docs ├── about.md ├── assets │ ├── Microsoft.png │ └── mdc.png ├── index.md ├── mitigations │ ├── MS-M9001 Multi-factor Authentication.md │ ├── MS-M9002 Restrict access to the API server using IP firewall.md │ ├── MS-M9003 Adhere to least-privilege principle.md │ ├── MS-M9004 Secure CI CD environment.md │ ├── MS-M9005 │ │ ├── MS-M9005.001 Gate generated images in CI CD pipeline.md │ │ ├── MS-M9005.002 Gate images pushed to registries.md │ │ ├── MS-M9005.003 Gate images deployed to Kubenertes cluster.md │ │ └── index.md │ ├── MS-M9006 Enable Just In Time access to API server.md │ ├── MS-M9007 Network Intrusion Prevention.md │ ├── MS-M9008 Limit Access to Services Over Network.md │ ├── MS-M9009 Require Strong Authentication to Services.md │ ├── MS-M9010 Restrict Exec Commands on Pods.md │ ├── MS-M9011 Restrict Container Runtime using LSM.md │ ├── MS-M9012 Remove Tools from Container Images.md │ ├── MS-M9013 Restrict over permissive containers.md │ ├── MS-M9014 Network Segmentation.md │ ├── MS-M9015 Avoid Running Management Interface on Containers.md │ ├── MS-M9016 Restrict File and Directory Permissions.md │ ├── MS-M9017 Ensure that pods meet defined Pod Security Standards.md │ ├── MS-M9018 Restricting cloud metadata API access.md │ ├── MS-M9019 Allocate specific identities to pods.md │ ├── MS-M9020 Collect Logs to Remote Data Storage.md │ ├── MS-M9021 Restrict the usage of unauthenticated APIs in the Cluster.md │ ├── MS-M9022 Use Managed Secret Store.md │ ├── MS-M9023 Remove unused secrets from the cluster.md │ ├── MS-M9024 Restrict access to etcd.md │ ├── MS-M9025 Disable Service Account Auto Mount.md │ ├── MS-M9026 Avoid using plain text credentials in configuration files.md │ ├── MS-M9027 Use NodeRestriction Admission Controller.md │ ├── MS-M9028 Use CNIs that are not prone to ARP poisoning.md │ ├── MS-M9029 Set requests and limits for containers.md │ ├── MS-M9030 Use Cloud Storage Provider.md │ ├── MS-M9031 Implement Data Backup Strategy.md │ ├── MS-M9032 Avoid using web-hosted manifest for Kubelet.md │ └── index.md ├── stylesheets │ └── extra.css ├── tactics │ ├── Collection │ │ └── index.md │ ├── CredentialAccess │ │ └── index.md │ ├── DefenseEvasion │ │ └── index.md │ ├── Discovery │ │ └── index.md │ ├── Execution │ │ └── index.md │ ├── Impact │ │ └── index.md │ ├── InitialAccess │ │ └── index.md │ ├── LateralMovement │ │ └── index.md │ ├── Persistence │ │ └── index.md │ └── PrivilegeEscalation │ │ └── index.md └── techniques │ ├── ARP poisoning and IP spoofing.md │ ├── Access Kubelet API.md │ ├── Access cloud resources.md │ ├── Access managed identity credentials.md │ ├── Access the K8S API server.md │ ├── Application Exploit (RCE).md │ ├── Application Vulnerability.md │ ├── Application credentials in configuration files.md │ ├── Backdoor container.md │ ├── Clear container logs.md │ ├── Cluster internal networking.md │ ├── Cluster-admin binding.md │ ├── Collecting Data from Pod.md │ ├── Compromised Image In Registry.md │ ├── Connect from Proxy server.md │ ├── CoreDNS poisoning.md │ ├── Data destruction.md │ ├── Delete K8S events.md │ ├── Denial of service.md │ ├── Exec into container.md │ ├── Exposed sensitive interfaces.md │ ├── Instance Metadata API.md │ ├── Kubeconfig file.md │ ├── Kubernetes CronJob.md │ ├── List K8S secrets.md │ ├── Malicious admission controller.md │ ├── Mount service principal.md │ ├── Network mapping.md │ ├── New Container.md │ ├── Pod or container name similarily.md │ ├── Privileged container.md │ ├── Resource hijacking.md │ ├── SSH server running inside container.md │ ├── Sidecar Injection.md │ ├── Static Pods.md │ ├── Using Cloud Credentials.md │ ├── Writable hostPath mount.md │ ├── bash or cmd inside container.md │ ├── container service account.md │ └── images from a private registry.md ├── mkdocs.yml └── serve_docs.bat /.github/workflows/main.yml: -------------------------------------------------------------------------------- 1 | name: build doc pages 2 | on: 3 | push: 4 | branches: [ "main" ] 5 | 6 | # Allows you to run this workflow manually from the Actions tab 7 | workflow_dispatch: 8 | 9 | jobs: 10 | build: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - name: Checkout Repository 14 | uses: actions/checkout@v3 15 | - name: Install Python 16 | uses: actions/setup-python@v4.2.0 17 | with: 18 | python-version: 3.x 19 | - name: Install Dependencies 20 | run: pip install mkdocs-material 21 | - name: Publish Pages to gh-deploy 22 | run: mkdocs gh-deploy --force 23 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .env/ 2 | site/ 3 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Microsoft Open Source Code of Conduct 2 | 3 | This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). 4 | 5 | Resources: 6 | 7 | - [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/) 8 | - [Microsoft Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) 9 | - Contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with questions or concerns 10 | -------------------------------------------------------------------------------- /LICENSE.TXT: -------------------------------------------------------------------------------- 1 | Threat Matrix for Kubernetes 2 | 3 | Creative Commons Attribution 4.0 International Public License 4 | By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution 4.0 International Public License ("Public License"). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions. 5 | 6 | Section 1 – Definitions. 7 | 8 | Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image. 9 | Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License. 10 | Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights. 11 | Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements. 12 | Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material. 13 | Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License. 14 | Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license. 15 | Licensor means the individual(s) or entity(ies) granting rights under this Public License. 16 | Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them. 17 | Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world. 18 | You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning. 19 | Section 2 – Scope. 20 | 21 | License grant. 22 | Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to: 23 | reproduce and Share the Licensed Material, in whole or in part; and 24 | produce, reproduce, and Share Adapted Material. 25 | Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions. 26 | Term. The term of this Public License is specified in Section 6(a). 27 | Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material. 28 | Downstream recipients. 29 | Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License. 30 | No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material. 31 | No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i). 32 | Other rights. 33 | 34 | Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise. 35 | Patent and trademark rights are not licensed under this Public License. 36 | To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties. 37 | Section 3 – License Conditions. 38 | 39 | Your exercise of the Licensed Rights is expressly made subject to the following conditions. 40 | 41 | Attribution. 42 | 43 | If You Share the Licensed Material (including in modified form), You must: 44 | 45 | retain the following if it is supplied by the Licensor with the Licensed Material: 46 | identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated); 47 | a copyright notice; 48 | a notice that refers to this Public License; 49 | a notice that refers to the disclaimer of warranties; 50 | a URI or hyperlink to the Licensed Material to the extent reasonably practicable; 51 | indicate if You modified the Licensed Material and retain an indication of any previous modifications; and 52 | indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License. 53 | You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information. 54 | If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable. 55 | If You Share Adapted Material You produce, the Adapter's License You apply must not prevent recipients of the Adapted Material from complying with this Public License. 56 | Section 4 – Sui Generis Database Rights. 57 | 58 | Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material: 59 | 60 | for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database; 61 | if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material; and 62 | You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. 63 | For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights. 64 | Section 5 – Disclaimer of Warranties and Limitation of Liability. 65 | 66 | Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You. 67 | To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You. 68 | The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability. 69 | Section 6 – Term and Termination. 70 | 71 | This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically. 72 | Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates: 73 | 74 | automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or 75 | upon express reinstatement by the Licensor. 76 | For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License. 77 | For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License. 78 | Sections 1, 5, 6, 7, and 8 survive termination of this Public License. 79 | Section 7 – Other Terms and Conditions. 80 | 81 | The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed. 82 | Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License. 83 | Section 8 – Interpretation. 84 | 85 | For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License. 86 | To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions. 87 | No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor. 88 | Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Threat Matrix for Kubernetes 2 | 3 | Microsoft Defender for Cloud threat matrix for Kubernetes contains attack tactics, techniques and mitigations relevant for Kubernetes environment. 4 | 5 | The threat matrix is best viewed online via: [http://aka.ms/KubernetesThreatMatrix](http://aka.ms/KubernetesThreatMatrix) 6 | 7 | [![build doc pages](https://github.com/microsoft/Threat-Matrix-for-Kubernetes/actions/workflows/main.yml/badge.svg)](https://github.com/microsoft/Threat-Matrix-for-Kubernetes/actions/workflows/main.yml) 8 | [![pages-build-deployment](https://github.com/microsoft/Threat-Matrix-for-Kubernetes/actions/workflows/pages/pages-build-deployment/badge.svg)](https://github.com/microsoft/Threat-Matrix-for-Kubernetes/actions/workflows/pages/pages-build-deployment) 9 | 10 | ## Contributing 11 | 12 | This project welcomes contributions and suggestions. Most contributions require you to agree to a 13 | Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us 14 | the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com. 15 | 16 | When you submit a pull request, a CLA bot will automatically determine whether you need to provide 17 | a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions 18 | provided by the bot. You will only need to do this once across all repos using our CLA. 19 | 20 | This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). 21 | For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or 22 | contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments. 23 | 24 | ## Trademarks 25 | 26 | This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft 27 | trademarks or logos is subject to and must follow 28 | [Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general). 29 | Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. 30 | Any use of third-party trademarks or logos are subject to those third-party's policies. 31 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | ## Security 4 | 5 | Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [our GitHub organizations](https://opensource.microsoft.com/). 6 | 7 | If you believe you have found a security vulnerability in any Microsoft-owned repository that meets [Microsoft's definition of a security vulnerability](https://aka.ms/opensource/security/definition), please report it to us as described below. 8 | 9 | ## Reporting Security Issues 10 | 11 | **Please do not report security vulnerabilities through public GitHub issues.** 12 | 13 | Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://aka.ms/opensource/security/create-report). 14 | 15 | If you prefer to submit without logging in, send email to [secure@microsoft.com](mailto:secure@microsoft.com). If possible, encrypt your message with our PGP key; please download it from the [Microsoft Security Response Center PGP Key page](https://aka.ms/opensource/security/pgpkey). 16 | 17 | You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://aka.ms/opensource/security/msrc). 18 | 19 | Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue: 20 | 21 | * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.) 22 | * Full paths of source file(s) related to the manifestation of the issue 23 | * The location of the affected source code (tag/branch/commit or direct URL) 24 | * Any special configuration required to reproduce the issue 25 | * Step-by-step instructions to reproduce the issue 26 | * Proof-of-concept or exploit code (if possible) 27 | * Impact of the issue, including how an attacker might exploit the issue 28 | 29 | This information will help us triage your report more quickly. 30 | 31 | If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://aka.ms/opensource/security/bounty) page for more details about our active programs. 32 | 33 | ## Preferred Languages 34 | 35 | We prefer all communications to be in English. 36 | 37 | ## Policy 38 | 39 | Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://aka.ms/opensource/security/cvd). 40 | 41 | 42 | -------------------------------------------------------------------------------- /SUPPORT.md: -------------------------------------------------------------------------------- 1 | # Support 2 | 3 | ## How to file issues and get help 4 | 5 | This project uses GitHub Issues to track bugs and feature requests. Please search the existing 6 | issues before filing new issues to avoid duplicates. For new issues, file your bug or 7 | feature request as a new Issue. 8 | 9 | ## Microsoft Support Policy 10 | 11 | Support for this **Threat Matrix for Kubernetes** is limited to the resources listed above. 12 | -------------------------------------------------------------------------------- /docs/about.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - navigation 4 | - toc 5 | - footer 6 | --- 7 | 8 | # About 9 | 10 | The purpose of the threat matrix for Kubernetes is to conceptualize the known tactics, techniques, and procedures (TTP) that adversaries may use against Kubernetes environments. Inspired from MITRE ATT&CK, the threat matrix for Kubernetes is designed to give quick insight into a potential TTP that an adversary may be using in their attack campaign. The threat matrix for Kubernetes contains also mitigations specific to Kubernetes environments and attack techniques. 11 | 12 |
13 | 14 | # Acknowledgments 15 | 16 | The threat matrix for Kubernetes is created by Yossi Weizman, Dotan Patrich and Ram Pliskin of the Microsoft Defender for Cloud team. 17 | 18 | [MITRE ATT&CK © 2021 The MITRE Corporation](https://attack.mitre.org/resources/terms-of-use/) - This work is reproduced and distributed with the permission of The MITRE Corporation. 19 | 20 | -------------------------------------------------------------------------------- /docs/assets/Microsoft.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/Threat-Matrix-for-Kubernetes/b885d18bd4236286b59b735c5e18f2902823d2c2/docs/assets/Microsoft.png -------------------------------------------------------------------------------- /docs/assets/mdc.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/microsoft/Threat-Matrix-for-Kubernetes/b885d18bd4236286b59b735c5e18f2902823d2c2/docs/assets/mdc.png -------------------------------------------------------------------------------- /docs/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Tactics 8 | 9 | |[Initial Access](tactics/InitialAccess/index.md)|[Execution](tactics/Execution/index.md)|[Persistence](tactics/Persistence/index.md)|[Privilege Escalation](tactics/PrivilegeEscalation/index.md)|[Defense Evasion](tactics/DefenseEvasion/index.md)|[Credential Access](tactics/CredentialAccess/index.md)|[Discovery](tactics/Discovery/index.md)|[Lateral Movement](tactics/LateralMovement/index.md)|[Collection](tactics/Collection/index.md)|[Impact](tactics/Impact/index.md)| 10 | |--------------|---------|-----------|--------------------|---------------|-----------------|---------|----------------|----------|------| 11 | |[Using cloud credentials](techniques/Using%20Cloud%20Credentials.md)|[Exec into container](techniques/Exec%20into%20container.md)|[Backdoor container](techniques/Backdoor%20container.md)|[Privileged container](techniques/Privileged%20container.md)|[Clear container logs](techniques/Clear%20container%20logs.md)|[List K8S secrets](techniques/List%20K8S%20secrets.md)|[Access Kubernetes API server](techniques/Access%20the%20K8S%20API%20server.md)|[Access cloud resources](techniques/Access%20cloud%20resources.md)|[Images from a private registry](techniques/images%20from%20a%20private%20registry.md)|[Data destruction](techniques/Data%20destruction.md)| 12 | |[Compromised image In registry](techniques/Compromised%20Image%20In%20Registry.md)|[bash/cmd inside container](techniques/bash%20or%20cmd%20inside%20container.md)|[Writable hostPath mount](techniques/Writable%20hostPath%20mount.md)|[Cluster-admin binding](techniques/Cluster-admin%20binding.md)|[Delete K8S events](techniques/Delete%20K8S%20events.md)|[Mount service principal](techniques/Mount%20service%20principal.md)|[Access Kubelet API](techniques/Access%20Kubelet%20API.md)|[Container service account](techniques/container%20service%20account.md)|[Collecting data from pod](techniques/Collecting%20Data%20from%20Pod.md)|[Resource hijacking](techniques/Resource%20hijacking.md)| 13 | |[Kubeconfig file](techniques/Kubeconfig%20file.md)|[New container](techniques/New%20Container.md)|[Kubernetes CronJob](techniques/Kubernetes%20CronJob.md)|[hostPath mount](techniques/Writable%20hostPath%20mount.md)|[Pod / container name similarity](techniques/Pod%20or%20container%20name%20similarily.md)|[Container service account](techniques/container%20service%20account.md)|[Network mapping](techniques/Network%20mapping.md)|[Cluster internal networking](techniques/Cluster%20internal%20networking.md)||[Denial of service](techniques/Denial%20of%20service.md)| 14 | |[Application vulnerability](techniques/Application%20Vulnerability.md)|[Application exploit (RCE)](techniques/Application%20Exploit%20(RCE).md)|[Malicious admission controller](techniques/Malicious%20admission%20controller.md)|[Access cloud resources](techniques/Access%20cloud%20resources.md)|[Connect from proxy server](techniques/Connect%20from%20Proxy%20server.md)|[Application credentials in configuration files](techniques/Application%20credentials%20in%20configuration%20files.md)|[Exposed sensitive interfaces](techniques/Exposed%20sensitive%20interfaces.md)|[Application credentials in configuration files](techniques/Application%20credentials%20in%20configuration%20files.md)||| 15 | |[Exposed sensitive interfaces](techniques/Exposed%20sensitive%20interfaces.md)|[SSH server running inside container](techniques/SSH%20server%20running%20inside%20container.md)|[Container service account](techniques/container%20service%20account.md)|||[Access managed identity credentials](techniques/Access%20managed%20identity%20credentials.md)|[Instance Metadata API](techniques/Instance%20Metadata%20API.md)|[Writable hostPath mount](techniques/Writable%20hostPath%20mount.md)||| 16 | ||[Sidecar injection](techniques/Sidecar%20Injection.md)|[Static pods](techniques/Static%20Pods.md)|||[Malicious admission controller](techniques/Malicious%20admission%20controller.md)||[CoreDNS poisoning](techniques/CoreDNS%20poisoning.md)||| 17 | ||||||||[ARP poisoning and IP spoofing](techniques/ARP%20poisoning%20and%20IP%20spoofing.md)|| 18 | 19 | 20 | 21 | ???+ attention "Disclaimer" 22 | The purpose of the Threat Matrix for Kubernetes is to educate readers on the potential of Kubernetes-based tactics, techniques, and procedures (TTPs). It is not to teach how to weaponize or specifically abuse them. 23 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9001 Multi-factor Authentication.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Multi-factor authentication 8 | 9 | !!! info inline end 10 | ID: MS-M9001
11 | MITRE mitigation: [M1032](https://attack.mitre.org/mitigations/M1032/) 12 | 13 | Using multi-factor authentication for accounts can prevent unauthorized access in case an adversary achieves access to the account credentials. This can reduce the risk in case an adversary achieved valid credentials to an account that has permissions to the Kubernetes cluster. 14 | 15 | 16 | ## Techniques Addressed by Mitigation 17 | 18 | |ID|Name|Use| 19 | |--|----------|-----------| 20 | |[MS-TA9001](../techniques/Using%20Cloud%20Credentials.md)|Using cloud credentials|Use multi-factor authentication for cloud accounts which can be elevated to access Kubernetes clusters in that cloud.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9002 Restrict access to the API server using IP firewall.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Restrict access to the API server using IP firewall 8 | 9 | !!! info inline end 10 | ID: MS-M9002
11 | MITRE mitigation: [M1035](https://attack.mitre.org/mitigations/M1035/) 12 | 13 | Restricting access to the API server can prevent unwanted access to the clusters management, even if the adversary achieved valid credentials to the cluster. 14 | In managed clusters, cloud providers often support native built-in firewall which can restrict the IP addresses that are allowed to access the API server. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9001](../techniques/Using%20Cloud%20Credentials.md)|Using cloud credentials|Restrict access of cloud accounts to API server from trusted IP addresses only| 22 | |[MS-TA9003](../techniques/Kubeconfig%20file.md)|Kubeconfig file|Restrict access to the API server from known IP addresses| 23 | |[MS-TA9024](../techniques/Connect%20from%20Proxy%20server.md)|Connect from proxy server|Restrict access to the API server from known IP addresses| 24 | |[MS-TA9029](../techniques/Access%20the%20K8S%20API%20server.md)|Access Kubernetes API server|Restrict access to the API server from known IP addresses| 25 | |[MS-TA9040](../techniques/Denial%20of%20service.md)|Denial of service|Restrict access to the API server from known IP addresses| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9003 Adhere to least-privilege principle.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Adhere to least-privilege principle 8 | 9 | !!! info inline end 10 | ID: MS-M9003
11 | MITRE mitigation: [M1018](https://attack.mitre.org/mitigations/M1018/) 12 | 13 | 14 | Configure the Kubernetes role-based access controls (RBAC) for each user and service accounts to have only necessary permissions. This applies also to other, external, authorization providers such as Azure RBAC in AKS. 15 | 16 | In managed cluster, Kubernetes credentials are often retrieved or generated by the cloud provider via API call. To reduce the attack surface, grant permissions to the cloud provider API only to necessary accounts. In the case of Azure, make sure that only required identities have permissions to call: `/subscriptions/resourceGroups/providers/Microsoft.ContainerService/managedClusters/listClusterUserCredential` 17 | 18 | Kubeconfig file can contain credentials of accounts that allow interaction with a cluster. By applying least privileges principle to all accounts, can limit the impact of an account compromised through Kubeconfig file. 19 | 20 | Kubernetes project also lists the following recommendations for permissions and role assignment best practices: 21 | 22 | * Avoid wildcard permissions, especially to all resources. 23 | * Use RoleBinding instead of ClusterAdminBinding to give access within a namespace. 24 | * Avoid adding users to the system:master group as it bypasses RBAC. 25 | * Use impersonation rights for admins instead of adding to the cluster admin role. Audit and monitor when impersonation is being done. 26 | * Avoid granting the escalate or bind permissions to roles when not needed, audit and monitor when escalation is being made. 27 | * Avoid adding users to the system:unauthenticated group. 28 | * Limit permissions to [issue CSR and certificate](https://kubernetes.io/docs/concepts/security/rbac-good-practices/#csrs-and-certificate-issuing). 29 | * Avoid granting users with `create` rights on `serviceaccounts/token`, which could be exploited to create TokenRequests and issue tokens for existing service accounts. 30 | * Users with control over `validatingwebhookconfigurations` or `mutatingwebhookconfigurations` can control webhooks that can read any object admitted to the cluster, and in the case of mutating webhooks, also mutate admitted objects 31 | 32 | 33 | ## Techniques Addressed by Mitigation 34 | 35 | |ID|Name|Use| 36 | |--|----------|-----------| 37 | |[MS-TA9001](../techniques/Using%20Cloud%20Credentials.md)|Using cloud credentials|Limit RBAC privileges in the cloud account to retrieve access credentials to managed Kubenetes clusters.| 38 | |[MS-TA9003](../techniques/Kubeconfig%20file.md)|Kubeconfig file|Limit privileges and actions that can be achieved by getting access to a kubeconfig file| 39 | |[MS-TA9008](../techniques/New%20Container.md)|New container|Prevent unnecessary users and service accounts from creating new pods and controllers.| 40 | |[MS-TA9011](../techniques/Sidecar%20Injection.md)|Sidecar injection|Prevent unnecessary users and service accounts from creating new pods and controllers.| 41 | |[MS-TA9012](../techniques/Backdoor%20container.md)|Backdoor container|Prevent unnecessary users and service accounts from creating new pods and controllers.| 42 | |[MS-TA9014](../techniques/Kubernetes%20CronJob.md)|Kubernetes CronJob|Prevent unnecessary users and service accounts from creating new cronjobs.| 43 | |[MS-TA9015](../techniques/Malicious%20admission%20controller.md)|Malicious admission controller|Restrict permissions to deploy or modify `MutatingAdmissionWebhook` and `ValidatingAdmissionWebhook` objects.| 44 | |[MS-TA9019](../techniques/Cluster-admin%20binding.md)|Cluster-admin binding|Review privileged role binding and RBAC settings, restrict permissions to configure rolebinding and clusterrolebinding.| 45 | |[MS-TA9020](../techniques/Access%20cloud%20resources.md)|Access cloud resources|Grant only necessary permission to the cloud identities.| 46 | |[MS-TA9022](../techniques/Delete%20K8S%20events.md)|Delete Kubernetes events|Restrict permissions to delete Kubernetes events.| 47 | |[MS-TA9025](../techniques/List%20K8S%20secrets.md)|List Kubernetes secrets|Limit users and service accounts access to Kubernetes secrets.| 48 | |[MS-TA9026](../techniques/Mount%20service%20principal.md)|Mount service principal|Grant minimal required permissions to service principals| 49 | |[MS-TA9016](../techniques/container%20service%20account.md)|Container Service Account|Configure the Kubernetes RBAC such that each service account will have the minimal necessary permissions for the application’s functionality.| 50 | |[MS-TA9029](../techniques/Access%20the%20K8S%20API%20server.md)|Access Kubernetes API Server|Configure the Kubernetes RBAC such as each service account has only the minimal necessary permissions for the application’s functionality.| 51 | |[MS-TA9030](../techniques/Access%20Kubelet%20API.md)|Access Kubelet API|Kubelet uses Kubernetes RBAC to authorize requests to its API, when `Webhook` is used as authorization mode. In this mode, Kubelet sends a `SubjectAccessReview` to the API server to check if the identity is authorized to perform the required action. Configure the Kubernetes RBAC such as only service accounts that should legitimacy communicate with Kubelet API have the relevant permissions.| 52 | |[MS-TA9035](../techniques/CoreDNS%20poisoning.md)|CoreDNS poisoning|Limit updates permissions to the CoreDNS ConfigMap object.| 53 | |[MS-TA9037](../techniques/images%20from%20a%20private%20registry.md)|Images from a private registry|In some configurations, the credentials to private registries are stored as Kubernetes secret. Adhere to least-privilege principle to prevent users from reading image pull secrets.| 54 | |[MS-TA9041](../techniques/Collecting%20Data%20from%20Pod.md)|Collecting data from pod|Adhere to least-privilege principle to prevent users from checkpoint or running kubectl cp commands. `kubectl cp` wraps exec command which runs a tar process. Preventing exec into a container would effectively restrict `kubectl cp` command.| 55 | |[MS-TA9006](../techniques/Exec%20into%20container.md)|Exec into container|Adhere to least-privilege principle to prevent users from exec into containers| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9004 Secure CI CD environment.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Secure CI/CD environment 8 | 9 | !!! info inline end 10 | ID: MS-M9004
11 | MITRE mitigation: - 12 | 13 | 14 | Security code repositories and CI/CD environment by placing gates to restrict unauthorized access and modification of content. This can include enforcing RBAC permissions to access and make changes to code, artifacts and build pipelines, ensure governed process for pull-request approval, apply branch policies and others. 15 | 16 | 17 | 18 | ## Techniques Addressed by Mitigation 19 | 20 | |ID|Name|Use| 21 | |--|----------|-----------| 22 | |[MS-TA9002](../techniques/Compromised%20Image%20In%20Registry.md)|Compromised image in registry|Placing gates in the CI\CD process can block pushing unsecured code to the image registry.| 23 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9005/MS-M9005.001 Gate generated images in CI CD pipeline.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Gate generated images in CI/CD pipeline 8 | 9 | !!! info inline end 10 | ID: MS-M9005.001
11 | Sub-mitigation of: [MS-M9005](./index.md) 12 | MITRE mitigation: [M1016](https://attack.mitre.org/mitigations/M1016/), [M1045](https://attack.mitre.org/mitigations/M1045/) 13 | 14 | 15 | Placing gates in the CI\CD pipeline that can cancel or fail pipeline execution to block container images not meeting content trust requirements. 16 | 17 | 18 | ## Techniques Addressed by Mitigation 19 | 20 | |ID|Name|Use| 21 | |--|----|---| 22 | |[MS-TA9002](../../techniques/Compromised%20Image%20In%20Registry.md)|Compromised image in registry|Ensure that only images that passed the security compliance policies are pushed to registries and deployed to Kubernetes clusters.| 23 | |[MS-TA9004](../../techniques/Application%20Vulnerability.md)|Application vulnerability|Scan images for vulnerabilities| 24 | |[MS-TA9009](../../techniques/Application%20Exploit%20(RCE).md)|Application exploit (RCE)|Block vulnerable images| 25 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9005/MS-M9005.002 Gate images pushed to registries.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Gate images pushed to registries 8 | 9 | !!! info inline end 10 | ID: MS-M9005.002
11 | Sub-mitigation of: [MS-M9005](./index.md) 12 | MITRE mitigation: [M1016](https://attack.mitre.org/mitigations/M1016/), [M1045](https://attack.mitre.org/mitigations/M1045/) 13 | 14 | 15 | Placing gates in the container registry to prevent pushing or quarantine images that does not meet the content trust requirement. Some container registries can support gates that will prevent pushing images, while others might quarantine images after they were already push to the registry. Ensuring that gates exists at the registry level can help preventing bypass of gates at the CI/CD pipelines level. 16 | 17 | 18 | ## Techniques Addressed by Mitigation 19 | 20 | |ID|Name|Use| 21 | |--|----|---| 22 | |[MS-TA9002](../../techniques/Compromised%20Image%20In%20Registry.md)|Compromised image in registry|Ensure that only images that passed the security compliance policies are pushed to registries and deployed to Kubernetes clusters.| 23 | |[MS-TA9004](../../techniques/Application%20Vulnerability.md)|Application vulnerability|Scan images for vulnerabilities| 24 | |[MS-TA9009](../../techniques/Application%20Exploit%20(RCE).md)|Application exploit (RCE)|Block vulnerable images| 25 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9005/MS-M9005.003 Gate images deployed to Kubenertes cluster.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Gate images deployed to Kubernetes cluster 8 | 9 | !!! info inline end 10 | ID: MS-M9005.003
11 | Sub-mitigation of: [MS-M9005](./index.md) 12 | MITRE mitigation: [M1016](https://attack.mitre.org/mitigations/M1016/), [M1045](https://attack.mitre.org/mitigations/M1045/) 13 | 14 | 15 | Gate deployment of images to Kubernetes cluster to prevent deploying images that does not meet the content trust requirements. This can include limiting images to be deployed only from trusted registries, to have digital signature or pass vulnerability scanning and other checks. This can prevent potential adversaries from using their own malicious images in the cluster. Also, this ensures that only images that passed the security compliance policies of the organization are deployed in the cluster. Kubernetes admission controller mechanism is one of the commonly used tools for implementing such policy. 16 | 17 | 18 | ## Techniques Addressed by Mitigation 19 | 20 | |ID|Name|Use| 21 | |--|----|---| 22 | |[MS-TA9002](../../techniques/Compromised%20Image%20In%20Registry.md)|Compromised image in registry|Ensure that only images that passed the security compliance policies are pushed to registries and deployed to Kubernetes clusters.| 23 | |[MS-TA9004](../../techniques/Application%20Vulnerability.md)|Application vulnerability|Scan images for vulnerabilities| 24 | |[MS-TA9008](../../techniques/New%20Container.md)|New container|Restrict deployment of new containers from trusted supply chain| 25 | |[MS-TA9009](../../techniques/Application%20Exploit%20(RCE).md)|Application exploit (RCE)|Block vulnerable images| 26 | |[MS-TA9011](../../techniques/Sidecar%20Injection.md)|Sidecar injection|Restrict deployment of new containers from trusted supply chain| 27 | |[MS-TA9012](../../techniques/Backdoor%20container.md)|Backdoor container|Restrict deployment of new containers from trusted supply chain| 28 | |[MS-TA9014](../../techniques/Kubernetes%20CronJob.md)|Kubernetes CronJob|Restrict deployment of new containers from trusted supply chain| 29 | |[MS-TA9018](../../techniques/Privileged%20container.md)|Privileged container|Restrict deployment of new containers from trusted supply chain| 30 | |[MS-TA9023](../../techniques/Pod%20or%20container%20name%20similarily.md)|Pod or container name similarity|Restrict deployment of new containers from trusted supply chain| 31 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9005/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Image assurance policy 8 | 9 | !!! info inline end 10 | ID: MS-M9005
11 | MITRE mitigation: [M1016](https://attack.mitre.org/mitigations/M1016/), [M1045](https://attack.mitre.org/mitigations/M1045/) 12 | 13 | 14 | Apply image assurance policy to evaluate container images against vulnerabilities, malware, exposed secrets or other policies. By ensuring consistent and comprehensive image assurance policy across the build, ship and run development stages. 15 | 16 | One approach of ensuring images passes assurance or compliance checks it to sign the container images, so the image signature can be checks downstream when deploying to Kubernetes clusters at runtime. 17 | 18 | 19 | !!! abstract "Sub-mitigations" 20 | 21 | |ID|Name| 22 | |--|----| 23 | |[MS-M9005.001](./MS-M9005.001%20Gate%20generated%20images%20in%20CI%20CD%20pipeline.md)|[Gate generated images in CI/CD pipeline](./MS-M9005.001%20Gate%20generated%20images%20in%20CI%20CD%20pipeline.md)| 24 | |[MS-M9005.002](./MS-M9005.002%20Gate%20images%20pushed%20to%20registries.md)|[Gate images pushed to registries](./MS-M9005.002%20Gate%20images%20pushed%20to%20registries.md)| 25 | |[MS-M9005.003](./MS-M9005.003%20Gate%20images%20deployed%20to%20Kubenertes%20cluster.md)|[Gate images deployed to Kubernetes cluster](./MS-M9005.003%20Gate%20images%20deployed%20to%20Kubenertes%20cluster.md)| 26 | 27 | 28 | 29 | 30 | ## Techniques Addressed by Mitigation 31 | 32 | |ID|Name|Use| 33 | |--|----|---| 34 | |[MS-TA9002](../../techniques/Compromised%20Image%20In%20Registry.md)|Compromised image in registry|Ensure that only images that passed the security compliance policies are pushed to registries and deployed to Kubernetes clusters.| 35 | |[MS-TA9004](../../techniques/Application%20Vulnerability.md)|Application vulnerability|Scan images for vulnerabilities| 36 | |[MS-TA9009](../../techniques/Application%20Exploit%20(RCE).md)|Application exploit (RCE)|Block vulnerable images| 37 | |[MS-TA9034](../../techniques/Cluster%20internal%20networking.md)|Cluster internal networking|Avoid deployment of vulnerable applications to the cluster| 38 | 39 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9006 Enable Just In Time access to API server.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Enable Just In Time access to API server 8 | 9 | !!! info inline end 10 | ID: MS-M9006
11 | MITRE mitigation: - 12 | 13 | 14 | Employing Just In Time (JIT) elevated access to Kubernetes API server helps reduce the attack surface to the API server by compromised accounts by allowing access only at specific times, and through a governed escalation process. Enabling JIT access in Kubernetes is often done together with OpenID authentication which includes processes and tools to manage JIT access. One example of such OpenID authentication is Azure Active Directory authentication to Kubernetes clusters. The JIT approval is performed in the cloud control-plane level. Therefore, even if attackers have access to an account credentials, their access to the cluster is limited. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9003](../techniques/Kubeconfig%20file.md)|Kubeconfig file|Enable JIT elevated access to API server to limit attack surface or impact.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9007 Network Intrusion Prevention.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Network intrusion prevention 8 | 9 | !!! info inline end 10 | ID: MS-M9007
11 | MITRE mitigation: [M1031](https://attack.mitre.org/mitigations/M1031/) 12 | 13 | 14 | Use intrusion detection signatures and web application firewall to block traffic at network boundaries to pods and services in a Kubernetes cluster. 15 | 16 | Adapting the network intrusion prevention solution to Kubernetes environment might be needed to route network traffic destined to services through it. 17 | In some cases, this will be done by deploying a containerized version of a network intrusion prevention solution to the Kubernetes cluster and be part of the cluster network, and in some cases, routing ingress traffic to Kubernetes services through an external appliance, requiring that all ingress traffic will only come from such an appliance. 18 | 19 | 20 | ## Techniques Addressed by Mitigation 21 | 22 | |ID|Name|Use| 23 | |--|----------|-----------| 24 | |[MS-TA9004](../techniques/Application%20Vulnerability.md)|Application vulnerability|Use network intrusion prevention to block exploiting vulnerabilities.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9008 Limit Access to Services Over Network.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Limit access to services over network 8 | 9 | !!! info inline end 10 | ID: MS-M9008
11 | MITRE mitigation: [M1035](https://attack.mitre.org/mitigations/M1035/) 12 | 13 | 14 | Avoid exposing sensitive interfaces insecurely to the Internet or limit access to it. Sensitive interfaces includes management tools and applications that allow creation of new containers in the cluster. Some of those services does not use authentication by default and are not intended to be exposed. Examples of services that were exploited: Weave Scope, Apache NiFi and more. 15 | 16 | If services need to be exposed to the internet and are exposed using `LoadBalancer` service, use IP restriction (`loadBalancerSourceRanges`) when possible. This reduces the attack surface of the application and can prevent attackers from being able to reach the sensitive interfaces. 17 | 18 | 19 | ## Techniques Addressed by Mitigation 20 | 21 | |ID|Name|Use| 22 | |--|----------|-----------| 23 | |[MS-TA9005](../techniques/Exposed%20sensitive%20interfaces.md)|Exposed sensitive interfaces|Limit access to sensitive interface over the Internet| 24 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9009 Require Strong Authentication to Services.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Require strong authentication to services 8 | 9 | !!! info inline end 10 | ID: MS-M9009
11 | MITRE mitigation: - 12 | 13 | 14 | Use strong authentication when exposing sensitive interfaces to the Internet. For example, attacks were observed against exposed Kubeflow and Argo workloads that were not configured to use OpenID Connect or other authentication methods. 15 | 16 | Use strong authentication methods to the Kubernetes API that will prevent attackers from gaining access to the cluster even if valid credentials such as kubeconfig were achieved. For example, in AKS use AAD authentication instead of basic authentication. By using AAD authentication, a short-lived credential of the cluster is retrieved after authenticating to AAD. 17 | 18 | Avoid using the read-only endpoint of Kubelet in port `10255`, which doesn’t require authentication. In newer version of managed clusters, this port is disabled. 19 | 20 | ## Techniques Addressed by Mitigation 21 | 22 | |ID|Name|Use| 23 | |--|----------|-----------| 24 | |[MS-TA9005](../techniques/Exposed%20sensitive%20interfaces.md)|Exposed sensitive interfaces|Require strong authentication to exposed services| 25 | |[MS-TA9024](../techniques/Connect%20from%20Proxy%20server.md)|Connect from proxy server|Limit usage of kubeconfig authentication to the API server| 26 | |[MS-TA9030](../techniques/Access%20Kubelet%20API.md)|Access Kubelet API|Avoid using the unsecured port 10255 for the Kubelet API| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9010 Restrict Exec Commands on Pods.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Restrict exec commands on pods 8 | 9 | !!! info inline end 10 | ID: MS-M9010
11 | MITRE mitigation: - 12 | 13 | 14 | Restrict running Kubenetes `exec` command on sensitive\production containers using admission controller. This can prevent attackers from running malicious code on containers in cases when he `pods/exec` permission was obtained. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9006](../techniques/Exec%20into%20container.md)|Exec into container|Restrict exec commands on pods using admissions controller.| 22 | |[MS-TA9041](../techniques/Collecting%20Data%20from%20Pod.md)|Collecting data from pod|Restrict checkpoint and other commands on pods using admissions controller.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9011 Restrict Container Runtime using LSM.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Restrict container runtime using LSM 8 | 9 | !!! info inline end 10 | ID: MS-M9011
11 | MITRE mitigation: [M1038](https://attack.mitre.org/mitigations/M1038/), [M1040](https://attack.mitre.org/mitigations/M1040/) 12 | 13 | 14 | Restrict the running environment of the containers using Linux security modules, such as AppArmor, SELinux, Seccomp and others. Linux security modules can restrict access to files, running processes, certain system calls and others. Also, dropping unnecessary Linux capabilities from the container runtime environment helps reduce the attack surface of such container. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9006](../techniques/Exec%20into%20container.md)|Exec into container|Restrict container runtime capabilities using LSM.| 22 | |[MS-TA9007](../techniques/bash%20or%20cmd%20inside%20container.md)|Bash or Cmd inside container|Restrict container runtime capabilities using LSM.| 23 | |[MS-TA9009](../techniques/Application%20Exploit%20(RCE).md)|Application exploit (RCE)|Restrict container runtime capabilities using LSM.| 24 | |[MS-TA9010](../techniques/SSH%20server%20running%20inside%20container.md)|SSH server running inside container|Limit which process can open network socket on a container.| 25 | |[MS-TA9013](../techniques/Writable%20hostPath%20mount.md)|Writable hostPath mount|Use AppArmor to restrict file writing.| 26 | |[MS-TA9039](../techniques/Resource%20hijacking.md)|Resource hijacking|Restrict execution of unwanted processes in containers.| 27 | |[MS-TA9040](../techniques/Denial%20of%20service.md)|Denial of service|Restrict execution of unwanted processes in containers.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9012 Remove Tools from Container Images.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Remove tools from container images 8 | 9 | !!! info inline end 10 | ID: MS-M9012
11 | MITRE mitigation: [M1042](https://attack.mitre.org/mitigations/M1042/) 12 | 13 | 14 | Attackers often use built-in executables to run their malicious code. Removing unused executables from the image filesystem can prevent such activity. Examples of executables that are commonly used in malicious activity include: sh, bash, curl, wget, chmod and more. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9007](../techniques/bash%20or%20cmd%20inside%20container.md)|Bash or Cmd inside container|Remove bash and other terminals from container images.| 22 | |[MS-TA9039](../techniques/Resource%20hijacking.md)|Resource hijacking|Remove unused tools from the container image.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9013 Restrict over permissive containers.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Restrict over permissive containers 8 | 9 | !!! info inline end 10 | ID: MS-M9013
11 | MITRE mitigation: [M1038](https://attack.mitre.org/mitigations/M1038/) 12 | 13 | 14 | Use admission controller to prevent deploying containers with over-permissive capabilities or configuration in the cluster. This can include restricting privileged containers, containers with sensitive volumes, containers with excessive capabilities, and other signs of over permissive containers. 15 | 16 | In AKS clusters which are configured to use service principal, the service principal credentials are stored in the `/etc/kubernetes/azure.json` file on the cluster nodes. Containers with access to a volume containing this file are considered as containers with sensitive mount. 17 | 18 | 19 | ## Techniques Addressed by Mitigation 20 | 21 | |ID|Name|Use| 22 | |--|----------|-----------| 23 | |[MS-TA9008](../techniques/New%20Container.md)|New container|Restrict over permissive containers in the cluster using admission controller.| 24 | |[MS-TA9011](../techniques/Sidecar%20Injection.md)|Sidecar injection|Restrict over permissive containers in the cluster using admission controller.| 25 | |[MS-TA9012](../techniques/Backdoor%20container.md)|Backdoor container|Restrict over permissive containers in the cluster using admission controller.| 26 | |[MS-TA9013](../techniques/Writable%20hostPath%20mount.md)|Writable hostPath mount|Block sensitive volume mounts using admission controller.| 27 | |[MS-TA9014](../techniques/Kubernetes%20CronJob.md)|Kubernetes CronJob|Check cronjob pod template for sensitive mounts and excessive permissions.| 28 | |[MS-TA9018](../techniques/Privileged%20container.md)|Privileged container|Block Privileged containers using admission controller.| 29 | |[MS-TA9020](../techniques/Access%20cloud%20resources.md)|Access cloud resources|Block mounting volumes with access to cloud credentials.| 30 | |[MS-TA9026](../techniques/Mount%20service%20principal.md)|Mount service principal|Block sensitive volume mounts using admission controller| 31 | |[MS-TA9036](../techniques/ARP%20poisoning%20and%20IP%20spoofing.md)|ARP poisoning and IP spoofing|Avoid NET_RAW capability in containers which would enable sending crafted packets that perform ARP poisoning.| 32 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9014 Network Segmentation.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Network segmentation 8 | 9 | !!! info inline end 10 | ID: MS-M9014
11 | MITRE mitigation: [M1030](https://attack.mitre.org/mitigations/M1030/) 12 | 13 | 14 | Restrict inbound and outbound network traffic of the pods in the cluster. This includes inner-cluster communication as well as ingress\egress traffic to\from the cluster. Network Policies are a native K8s solution for networking restrictions in the cluster. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9009](../techniques/Application%20Exploit%20(RCE).md)|Application exploit (RCE)|Limit network access to containers| 22 | |[MS-TA9010](../techniques/SSH%20server%20running%20inside%20container.md)|SSH server running inside container|Limit network access to containers| 23 | |[MS-TA9024](../techniques/Connect%20from%20Proxy%20server.md)|Connect from proxy server|Limit network access from known proxy networks.| 24 | |[MS-TA9030](../techniques/Access%20Kubelet%20API.md)|Access Kubelet API|Restrict access of pods to the Kubelet API using Network Policy, blocking pod traffic to the ports 10250 and 10255.| 25 | |[MS-TA9031](../techniques/Network%20mapping.md)|Network segmentation|Restrict network between pods using network policies| 26 | |[MS-TA9005](../techniques/Exposed%20sensitive%20interfaces.md)|Exposed sensitive interfaces|Restrict network access to the sensitive interfaces.| 27 | |[MS-TA9034](../techniques/Cluster%20internal%20networking.md)|Cluster internal networking|Provision pod network policies to restrict the traffic between pods| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9015 Avoid Running Management Interface on Containers.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Avoid running management interface on containers 8 | 9 | !!! info inline end 10 | ID: MS-M9015
11 | MITRE mitigation: [M1042](https://attack.mitre.org/mitigations/M1042/) 12 | 13 | 14 | Avoid running SSH daemon, as well as other management interfaces, if they aren’t necessary for the application’s functionality. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9010](../techniques/SSH%20server%20running%20inside%20container.md)|SSH server running inside container|Avoid running SSH daemon on containers| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9016 Restrict File and Directory Permissions.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Restrict file and directory permissions 8 | 9 | !!! info inline end 10 | ID: MS-M9016
11 | MITRE mitigation: [M1022](https://attack.mitre.org/mitigations/M1022/) 12 | 13 | 14 | When using `hostPath` volumes, set it to “read-only” mode if possible. This prevents the container from writing to files in the underlying node and will harden an escape from the container to the node. 15 | 16 | Kubelet monitors a specific folder on the node which contains static pods manifest. By default the location of static pod manifest on nodes is at `/etc/kubernetes/manifests`. Restrict access of users to this folder to avoid deployments of unwanted static pods. 17 | 18 | 19 | ## Techniques Addressed by Mitigation 20 | 21 | |ID|Name|Use| 22 | |--|----------|-----------| 23 | |[MS-TA9013](../techniques/Writable%20hostPath%20mount.md)|Writable hostPath mount|Use read-only volumes.| 24 | |[MS-TA9021](../techniques/Clear%20container%20logs.md)|Clear container logs|Restrict access to container logs.| 25 | |[MS-TA9017](../techniques/Static%20Pods.md)|Static pods|Restrict write access to the Static pods manifest folder.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9017 Ensure that pods meet defined Pod Security Standards.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Ensure that pods meet defined Pod Security Standards 8 | 9 | !!! info inline end 10 | ID: MS-M9017
11 | MITRE mitigation: - 12 | 13 | 14 | The Pod Security Standards define three different policies to broadly cover the security spectrum. These policies are cumulative and range from highly-permissive to highly-restrictive. Decoupling policy definition from policy instantiation allows for a common understanding and consistent language of policies across clusters, independent of the underlying enforcement mechanism. At the same time, Kubernetes offers a built-in Pod Security admission controller to enforce the Pod Security Standards. Pod security restrictions are applied at the namespace level when pods are created. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9013](../techniques/Writable%20hostPath%20mount.md)|Writable hostPath mount|Use `Baseline` or `Restricted` pod security standards to prevent exploiting writable hostPath mount.| 22 | |[MS-TA9018](../techniques/Privileged%20container.md)|Privileged container|Restrict privileged containers using pod security standards.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9018 Restricting cloud metadata API access.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Restricting cloud metadata API access 8 | 9 | !!! info inline end 10 | ID: MS-M9018
11 | MITRE mitigation: [M1035](https://attack.mitre.org/mitigations/M1035/) 12 | 13 | 14 | Many cluster-to-cloud authentication methods involve access to the node’s metadata server. Restrict access to the metadata server if it’s not necessary. This can be done at the pod level by using networking restriction tools such as network policies. Alternatively, cloud providers allow this functionality in the node\cluster level. For instance, in AWS one can restrict the hop count limit of IMDS as described [here](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node). In AKS, deploying `AAD pod identity` would restrict access to IMDS. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9020](../techniques/Access%20cloud%20resources.md)|Access cloud resources|Restrict the access of pods to IMDS to restrict pods from getting access to cloud identities.| 22 | |[MS-TA9028](../techniques/Access%20managed%20identity%20credentials.md)|Access Managed Identity credentials|Restrict the access of pods to IMDS| 23 | |[MS-TA9033](../techniques/Instance%20Metadata%20API.md)|Instance Metadata API|Restrict the access of pods to IMDS| 24 | |[MS-TA9037](../techniques/images%20from%20a%20private%20registry.md)|Images from a private registry|Restrict access to IMDS to prevent authentication with a private registry using cloud identities.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9019 Allocate specific identities to pods.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Allocate specific identities to pods 8 | 9 | !!! info inline end 10 | ID: MS-M9019
11 | MITRE mitigation: - 12 | 13 | 14 | When needed, allocate dedicated cloud identity per pod with minimal permissions, instead of inheriting the node’s cloud identity. This prevents other pods from accessing cloud identities that are not necessary for their operation. The features that implement this separation are: Azure AD Pod Identity (AKS), Azure AD Workload identity (AKS), IRSA (EKS) and GCP Workload Identity (GCP). 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9020](../techniques/Access%20cloud%20resources.md)|Access cloud resources|Use dedicated allocated identities to pods| 22 | |[MS-TA9028](../techniques/Access%20managed%20identity%20credentials.md)|Access Managed Identity credentials|Allocate specific identities to pods.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9020 Collect Logs to Remote Data Storage.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Collect logs to remote data storage 8 | 9 | !!! info inline end 10 | ID: MS-M9020
11 | MITRE mitigation: [M1029](https://attack.mitre.org/mitigations/M1029/) 12 | 13 | 14 | Collect the Kubernetes and application logs of pods to external data storage to avoid tampering or deletion. This can be achieved by various open-source tools such as Fluentd. Also, built-in cloud solutions are available for managed clusters, such as Container Insights and Log Analytics in AKS and Cloud Logging in GKE. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9021](../techniques/Clear%20container%20logs.md)|Clear container logs|Collect container logs to a separate storage system.| 22 | |[MS-TA9022](../techniques/Delete%20K8S%20events.md)|Delete Kubernetes events|Collect Kubernetes logs to a separate storage system.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9021 Restrict the usage of unauthenticated APIs in the Cluster.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Restrict the usage of unauthenticated APIs in the cluster 8 | 9 | !!! info inline end 10 | ID: MS-M9021
11 | MITRE mitigation: - 12 | 13 | 14 | Some unmanaged clusters are misconfigured such as anonymous access is accepted by the Kubernetes API server. Make sure that the Kubernetes API is configured properly, and authentication and authorization mechanisms are set. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9024](../techniques/Connect%20from%20Proxy%20server.md)|Connect from proxy server|Restrict unauthenticated API to the Kubernetes API server.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9022 Use Managed Secret Store.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Use managed secret store 8 | 9 | !!! info inline end 10 | ID: MS-M9022
11 | MITRE mitigation: [M1029](https://attack.mitre.org/mitigations/M1029/) 12 | 13 | 14 | Use cloud secret store, such as Azure Key Vault, to securely store secrets that are used by the workloads in the cluster. This allows cloud-level management of the secret which includes permission management, expiration management, secret rotation, auditing, etc. The integration of cloud secret stores with Kubernetes is done by using Secrets Store CSI Driver, which is implemented by all major cloud providers. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9025](../techniques/List%20K8S%20secrets.md)|List Kubernetes secrets|Use cloud provider secret store to securely manage credentials in the cluster| 22 | |[MS-TA9027](../techniques/Application%20credentials%20in%20configuration%20files.md)|Application credentials in configuration files|Store secrets securely in managed secret stores| 23 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9023 Remove unused secrets from the cluster.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Remove unused secrets from the cluster 8 | 9 | !!! info inline end 10 | ID: MS-M9023
11 | MITRE mitigation: - 12 | 13 | 14 | Remove unused secrets objects from the cluster. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9025](../techniques/List%20K8S%20secrets.md)|List Kubernetes secrets|Remove unused secrets from the cluster.| 22 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9024 Restrict access to etcd.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Restrict access to etcd 8 | 9 | !!! info inline end 10 | ID: MS-M9024
11 | MITRE mitigation: [M1035](https://attack.mitre.org/mitigations/M1035/) 12 | 13 | 14 | Access to etcd should be limited to the Kubernetes control plane only. Depending on your configuration, you should attempt to use etcd over TLS. This mitigation is relevant only to non-managed Kubernetes environment, as access to etcd in cloud managed clusters is already restricted. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9025](../techniques/List%20K8S%20secrets.md)|List Kubernetes secrets|Restrict access to etcd.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9025 Disable Service Account Auto Mount.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Disable service account auto mount 8 | 9 | !!! info inline end 10 | ID: MS-M9025
11 | MITRE mitigation: - 12 | 13 | 14 | By default, a service account is mounted to every pod. If the application doesn’t require access to the Kubernetes API, disable the service account auto-mount by specifying `automountServiceAccountToken: false` in the pod configuration. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9016](../techniques/container%20service%20account.md)|Container service account|Disable service account auto mount.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9026 Avoid using plain text credentials in configuration files.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Avoid using plain text credentials 8 | 9 | !!! info inline end 10 | ID: MS-M9026
11 | MITRE mitigation: - 12 | 13 | 14 | Avoid using plain text credentials in configuration files. Use Kubernetes secrets or cloud secret store instead. This prevents unwanted access to plaintext credentials in source code, configuration files and Kubernetes objects. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9027](../techniques/Application%20credentials%20in%20configuration%20files.md)|Application credentials in configuration files|Avoid using plain text credentials in Kubernetes configuration| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9027 Use NodeRestriction Admission Controller.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Use NodeRestriction admission controller 8 | 9 | !!! info inline end 10 | ID: MS-M9027
11 | MITRE mitigation: - 12 | 13 | 14 | NodeRestriction admission controller limits the permissions of kubelet and allows it to modify only its own Node object and only the pods that are running on its own node. This may limit attackers who have access to the Kubelet API from gaining full control over the cluster. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9030](../techniques/Access%20Kubelet%20API.md)|Access Kubelet API|Limit Kubelet permissions to pods and nodes| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9028 Use CNIs that are not prone to ARP poisoning.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Use CNIs that are not prone to ARP poisoning 8 | 9 | !!! info inline end 10 | ID: MS-M9028
11 | MITRE mitigation: - 12 | 13 | 14 | Kubernetes default CNI (Kubenet) is prone to ARP poisoning. This allows pods to impersonate other pods in the cluster. 15 | Use alternative CNIs that are not prone to ARP poisoning in the cluster. 16 | 17 | 18 | ## Techniques Addressed by Mitigation 19 | 20 | |ID|Name|Use| 21 | |--|----------|-----------| 22 | |[MS-TA9036](../techniques/ARP%20poisoning%20and%20IP%20spoofing.md)|ARP poisoning and IP spoofing|Use CNIs that are not prone to ARP poisoning.| -------------------------------------------------------------------------------- /docs/mitigations/MS-M9029 Set requests and limits for containers.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Set requests and limits for containers 8 | 9 | !!! info inline end 10 | ID: MS-M9029
11 | MITRE mitigation: - 12 | 13 | 14 | Set requests and limits for each container to avoid resource contention and DoS attacks. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9040](../techniques/Denial%20of%20service.md)|Denial of service|Limit compute resources for containers.| 22 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9030 Use Cloud Storage Provider.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Use cloud storage provider 8 | 9 | !!! info inline end 10 | ID: MS-M9030
11 | MITRE mitigation: - 12 | 13 | 14 | Use cloud storage services, such as Azure Files, for storing the application’s data. Kubernetes integrates with all main cloud provider storage services as storage providers for pod volumes. This allows leveraging cloud storage capabilities such as backup and snapshots. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9038](../techniques/Data%20destruction.md)|Data destruction|Use Cloud Storage provider to persist application data.| 22 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9031 Implement Data Backup Strategy.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Implement data backup strategy 8 | 9 | !!! info inline end 10 | ID: MS-M9031
11 | MITRE mitigation: [M1053](https://attack.mitre.org/mitigations/M1053/) 12 | 13 | 14 | Take and store data backups from pod mounted volumes for critical workloads. Ensure backup and storage systems are hardened and kept separate from the Kubernetes environment to prevent compromise. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9038](../techniques/Data%20destruction.md)|Data destruction|Backup pod mounted volumes for critical workloads.| 22 | -------------------------------------------------------------------------------- /docs/mitigations/MS-M9032 Avoid using web-hosted manifest for Kubelet.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Avoid using web-hosted manifest for Kubelet 8 | 9 | !!! info inline end 10 | ID: MS-M9032
11 | MITRE mitigation: - 12 | 13 | 14 | Kubelet can deploy static pods by using manifests that are stored in web accessible locations. If web-hosted manifest are not required, make sure that Kubelet does not run with `--manifest-url` argument. 15 | 16 | 17 | ## Techniques Addressed by Mitigation 18 | 19 | |ID|Name|Use| 20 | |--|----------|-----------| 21 | |[MS-TA9017](../techniques/Static%20Pods.md)|Static pods|Avoid using web-hosted manifest for Kubelet.| 22 | -------------------------------------------------------------------------------- /docs/mitigations/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Mitigations 8 | 9 | Mitigations represent security concepts and classes of technologies that can be used to prevent a technique or sub-technique from being successfully executed. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-M9001](./MS-M9001%20Multi-factor%20Authentication.md)|Multi-factor authentication| 14 | |[MS-M9002](./MS-M9002%20Restrict%20access%20to%20the%20API%20server%20using%20IP%20firewall.md)|Restrict access to the API server using IP firewall| 15 | |[MS-M9003](./MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle| 16 | |[MS-M9004](./MS-M9004%20Secure%20CI%20CD%20environment.md)|Secure CI/CD environment| 17 | |[MS-M9005](./MS-M9005/index.md)|Image assurance policy| 18 | |[MS-M9006](./MS-M9006%20Enable%20Just%20In%20Time%20access%20to%20API%20server.md)|Enable Just In Time access to API server| 19 | |[MS-M9007](./MS-M9007%20Network%20Intrusion%20Prevention.md)|Network intrusion prevention| 20 | |[MS-M9008](./MS-M9008%20Limit%20Access%20to%20Services%20Over%20Network.md)|Limit access to services over network| 21 | |[MS-M9009](./MS-M9009%20Require%20Strong%20Authentication%20to%20Services.md)|Require strong authentication to services| 22 | |[MS-M9010](./MS-M9010%20Restrict%20Exec%20Commands%20on%20Pods.md)|Restrict exec commands on pods| 23 | |[MS-M9011](./MS-M9011%20Restrict%20Container%20Runtime%20using%20LSM.md)|Restrict container runtime using LSM| 24 | |[MS-M9012](./MS-M9012%20Remove%20Tools%20from%20Container%20Images.md)|Remove tools from container images| 25 | |[MS-M9013](./MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers| 26 | |[MS-M9014](./MS-M9014%20Network%20Segmentation.md)|Network segmentation| 27 | |[MS-M9015](./MS-M9015%20Avoid%20Running%20Management%20Interface%20on%20Containers.md)|Avoid running management interface on containers| 28 | |[MS-M9016](./MS-M9016%20Restrict%20File%20and%20Directory%20Permissions.md)|Restrict file and directory permissions| 29 | |[MS-M9017](./MS-M9017%20Ensure%20that%20pods%20meet%20defined%20Pod%20Security%20Standards.md)|Ensure that pods meet defined Pod Security Standards| 30 | |[MS-M9018](./MS-M9018%20Restricting%20cloud%20metadata%20API%20access.md)|Restricting cloud metadata API access| 31 | |[MS-M9019](./MS-M9019%20Allocate%20specific%20identities%20to%20pods.md)|Allocate specific identities to pods| 32 | |[MS-M9020](./MS-M9020%20Collect%20Logs%20to%20Remote%20Data%20Storage.md)|Collect logs to remote data storage| 33 | |[MS-M9021](./MS-M9021%20Restrict%20the%20usage%20of%20unauthenticated%20APIs%20in%20the%20Cluster.md)|Restrict the usage of unauthenticated APIs in the Cluster| 34 | |[MS-M9022](./MS-M9022%20Use%20Managed%20Secret%20Store.md)|Use managed secret store| 35 | |[MS-M9023](./MS-M9023%20Remove%20unused%20secrets%20from%20the%20cluster.md)|Remove unused secrets from the cluster| 36 | |[MS-M9024](./MS-M9024%20Restrict%20access%20to%20etcd.md)|Restrict access to etcd| 37 | |[MS-M9025](./MS-M9025%20Disable%20Service%20Account%20Auto%20Mount.md)|Disable service account auto mount| 38 | |[MS-M9026](./MS-M9026%20Avoid%20using%20plain%20text%20credentials%20in%20configuration%20files.md)|Avoid using plain text credentials| 39 | |[MS-M9027](./MS-M9027%20Use%20NodeRestriction%20Admission%20Controller.md)|Use NodeRestriction admission controller| 40 | |[MS-M9028](./MS-M9028%20Use%20CNIs%20that%20are%20not%20prone%20to%20ARP%20poisoning.md)|Use CNIs that are not prone to ARP poisoning| 41 | |[MS-M9029](./MS-M9029%20Set%20requests%20and%20limits%20for%20containers.md)|Set requests and limits for containers| 42 | |[MS-M9030](./MS-M9030%20Use%20Cloud%20Storage%20Provider.md)|Use cloud storage provider| 43 | |[MS-M9031](./MS-M9031%20Implement%20Data%20Backup%20Strategy.md)|Implement data backup strategy| 44 | |[MS-M9032](./MS-M9032%20Avoid%20using%20web-hosted%20manifest%20for%20Kubelet.md)|Avoid using web-hosted manifest for Kubelet| 45 | -------------------------------------------------------------------------------- /docs/stylesheets/extra.css: -------------------------------------------------------------------------------- 1 | .md-grid { 2 | max-width: 100rem; 3 | } -------------------------------------------------------------------------------- /docs/tactics/Collection/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Collection 8 | 9 | Collection in Kubernetes consists of techniques that are used by attackers to collect data from the cluster or through using the cluster. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-TA9037](../../techniques/images%20from%20a%20private%20registry.md)|Images from a private registry| 14 | |[MS-TA9041](../../techniques/Collecting%20Data%20from%20Pod.md)|Collecting data from pod| -------------------------------------------------------------------------------- /docs/tactics/CredentialAccess/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Credential Access 8 | 9 | The credential access tactic consists of techniques that are used by attackers to steal credentials. 10 | 11 | In containerized environments, this includes credentials of the running application, identities, secrets stored in the cluster, or cloud credentials. 12 | 13 | |ID|Name| 14 | |--|----| 15 | |[MS-TA9025](../../techniques/List%20K8S%20secrets.md)|List K8S secrets| 16 | |[MS-TA9026](../../techniques/Mount%20service%20principal.md)|Mount service principal| 17 | |[MS-TA9016](../../techniques/container%20service%20account.md)|Container service account| 18 | |[MS-TA9027](../../techniques/Application%20credentials%20in%20configuration%20files.md)|Application credentials in configuration files| 19 | |[MS-TA9028](../../techniques/Access%20managed%20identity%20credentials.md)|Access managed identity credentials| 20 | |[MS-TA9015](../../techniques/Malicious%20admission%20controller.md)|Malicious admission controller| -------------------------------------------------------------------------------- /docs/tactics/DefenseEvasion/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Defense Evasion 8 | 9 | The defense evasion tactic consists of techniques that are used by attackers to avoid detection and hide their activity. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-TA9021](../../techniques/Clear%20container%20logs.md)|Clear container logs| 14 | |[MS-TA9022](../../techniques/Delete%20K8S%20events.md)|Delete K8S events| 15 | |[MS-TA9023](../../techniques/Pod%20or%20container%20name%20similarily.md)|Pod / container name similarity| 16 | |[MS-TA9024](../../techniques/Connect%20from%20Proxy%20server.md)|Connect from proxy server| -------------------------------------------------------------------------------- /docs/tactics/Discovery/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Discovery 8 | 9 | The discovery tactic consists of techniques that are used by attackers to explore the environment to which they gained access. This exploration helps the attackers to perform lateral movement and gain access to additional resources. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-TA9029](../../techniques/Access%20the%20K8S%20API%20server.md)|Access Kubernetes API server| 14 | |[MS-TA9030](../../techniques/Access%20Kubelet%20API.md)|Access Kubelet API| 15 | |[MS-TA9031](../../techniques/Network%20mapping.md)|Network mapping| 16 | |[MS-TA9005](../../techniques/Exposed%20sensitive%20interfaces.md)|Exposed sensitive interfaces| 17 | |[MS-TA9033](../../techniques/Instance%20Metadata%20API.md)|Instance Metadata API| 18 | 19 | -------------------------------------------------------------------------------- /docs/tactics/Execution/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Execution 8 | 9 | The execution tactic consists of techniques that are used by attackers to run their code inside a cluster. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-TA9006](../../techniques/Exec%20into%20container.md)|Exec into container| 14 | |[MS-TA9007](../../techniques/bash%20or%20cmd%20inside%20container.md)|bash/cmd inside container| 15 | |[MS-TA9008](../../techniques/New%20Container.md)|New container| 16 | |[MS-TA9009](../../techniques/Application%20Exploit%20(RCE).md)|Application exploit (RCE)| 17 | |[MS-TA9010](../../techniques/SSH%20server%20running%20inside%20container.md)|SSH server running inside container| 18 | |[MS-TA9011](../../techniques/Sidecar%20Injection.md)|Sidecar injection| -------------------------------------------------------------------------------- /docs/tactics/Impact/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Impact 8 | 9 | The Impact tactic consists of techniques that are used by attackers to destroy, abuse, or disrupt the normal behavior of the environment. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-TA9038](../../techniques/Data%20destruction.md)|Data destruction| 14 | |[MS-TA9039](../../techniques/Resource%20hijacking.md)|Resource hijacking| 15 | |[MS-TA9040](../../techniques/Denial%20of%20service.md)|Denial of service| 16 | -------------------------------------------------------------------------------- /docs/tactics/InitialAccess/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Initial Access 8 | 9 | The initial access tactic consists of techniques that are used for gaining access to the resource. In containerized environments, those techniques enable first access to the cluster. This access can be achieved directly via the cluster management layer or, alternatively, by gaining access to a malicious or vulnerable resource that is deployed on the cluster. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-TA9001](../../techniques/Using%20Cloud%20Credentials.md)|Using cloud credentials| 14 | |[MS-TA9002](../../techniques/Compromised%20Image%20In%20Registry.md)|Compromised image in registry| 15 | |[MS-TA9003](../../techniques/Kubeconfig%20file.md)|Kubeconfig file| 16 | |[MS-TA9004](../../techniques/Application%20Vulnerability.md)|Application vulnerability| 17 | |[MS-TA9005](../../techniques/Exposed%20sensitive%20interfaces.md)|Exposed sensitive interfaces| -------------------------------------------------------------------------------- /docs/tactics/LateralMovement/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Lateral Movement 8 | 9 | The lateral movement tactic consists of techniques that are used by attackers to move through the victim’s environment. In containerized environments, this includes gaining access to various resources in the cluster from a given access to one container, gaining access to the underlying node from a container, or gaining access to the cloud environment. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-TA9020](../../techniques/Access%20cloud%20resources.md)|Access cloud resources| 14 | |[MS-TA9016](../../techniques/container%20service%20account.md)|Container service account| 15 | |[MS-TA9034](../../techniques/Cluster%20internal%20networking.md)|Cluster internal networking| 16 | |[MS-TA9027](../../techniques/Application%20credentials%20in%20configuration%20files.md)|Application credentials in configuration files| 17 | |[MS-TA9013](../../techniques/Writable%20hostPath%20mount.md)|Writable hostPath mount| 18 | |[MS-TA9035](../../techniques/CoreDNS%20poisoning.md)|CoreDNS poisoning| 19 | |[MS-TA9036](../../techniques/ARP%20poisoning%20and%20IP%20spoofing.md)|ARP poisoning and IP spoofing| 20 | -------------------------------------------------------------------------------- /docs/tactics/Persistence/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Persistence 8 | 9 | The persistence tactic consists of techniques that are used by attackers to keep access to the cluster in case their initial foothold is lost. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-TA9012](../../techniques/Backdoor%20container.md)|Backdoor container| 14 | |[MS-TA9013](../../techniques/Writable%20hostPath%20mount.md)|Writable hostPath mount| 15 | |[MS-TA9014](../../techniques/Kubernetes%20CronJob.md)|Kubernetes CronJob| 16 | |[MS-TA9015](../../techniques/Malicious%20admission%20controller.md)|Malicious admission controller| 17 | |[MS-TA9016](../../techniques/container%20service%20account.md)|Container service account| 18 | |[MS-TA9017](../../techniques/Static%20Pods.md)|Static pods| 19 | 20 | 21 | -------------------------------------------------------------------------------- /docs/tactics/PrivilegeEscalation/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Privilege Escalation 8 | 9 | The privilege escalation tactic consists of techniques that are used by attackers to get higher privileges in the environment than those they currently have. In containerized environments, this can include getting access to the node from a container, gaining higher privileges in the cluster, and even getting access to the cloud resources. 10 | 11 | |ID|Name| 12 | |--|----| 13 | |[MS-TA9018](../../techniques/Privileged%20container.md)|Privileged container| 14 | |[MS-TA9019](../../techniques/Cluster-admin%20binding.md)|Cluster-admin binding| 15 | |[MS-TA9013](../../techniques/Writable%20hostPath%20mount.md)|hostPath mount| 16 | |[MS-TA9020](../../techniques/Access%20cloud%20resources.md)|Access cloud resources| 17 | -------------------------------------------------------------------------------- /docs/techniques/ARP poisoning and IP spoofing.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # ARP poisoning and IP spoofing 8 | 9 | !!! info inline end 10 | ID: MS-TA9036
11 | Tactic: [Lateral Movement](../tactics/LateralMovement/index.md)
12 | MITRE technique: [T1557](https://attack.mitre.org/techniques/T1557/) 13 | 14 | Kubernetes has numerous network plugins (Container Network Interfaces or CNIs) that can be used in the cluster. Kubenet is the basic, and in many cases the default, network plugin. In this configuration, a bridge is created on each node (cbr0) to which the various pods are connected using veth pairs. The fact that cross-pod traffic is through a bridge, a level-2 component, means that performing ARP poisoning in the cluster is possible. Therefore, if attackers get access to a pod in the cluster, they can perform ARP poisoning, and spoof the traffic of other pods. By using this technique, attackers can perform several attacks at the network-level which can lead to lateral movements, such as DNS spoofing or stealing cloud identities of other pods (CVE-2021-1677). 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9013](../mitigations/MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers|Avoid NET_RAW capability in containers which would enable sending crafted packets that perform ARP poisoning.| 21 | |[MS-M9028](../mitigations/MS-M9028%20Use%20CNIs%20that%20are%20not%20prone%20to%20ARP%20poisoning.md)|Use CNIs that are not prone to ARP poisoning|Use CNIs that are not prone to ARP poisoning.| -------------------------------------------------------------------------------- /docs/techniques/Access Kubelet API.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Access Kubelet API 8 | 9 | !!! info inline end 10 | ID: MS-TA9030
11 | Tactic: [Discovery](../tactics/Discovery/index.md)
12 | MITRE technique: [T1613](https://attack.mitre.org/techniques/T1613/) 13 | 14 | Kubelet is the Kubernetes agent that is installed on each node. Kubelet is responsible for the proper execution of pods that are assigned to the node. Kubelet exposes a read-only API service that does not require authentication (TCP port 10255). Attackers with network access to the host (for example, via running code on a compromised container) can send API requests to the Kubelet API. Specifically querying https://[NODE IP]:10255/pods/ retrieves the running pods on the node. https://[NODE IP]:10255/spec/ retrieves information about the node itself, such as CPU and memory consumption. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9009](../mitigations/MS-M9009%20Require%20Strong%20Authentication%20to%20Services.md)|Require Strong Authentication to Services|Avoid using the unsecured port 10255 for the Kubelet API| 21 | |[MS-M9014](../mitigations/MS-M9014%20Network%20Segmentation.md)|Network Segmentation|Restrict access of pods to the Kubelet API using Network Policy, blocking pod traffic to the ports 10250 and 10255.| 22 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Kubelet uses Kubernetes RBAC to authorize requests to its API, when `Webhook` is used as authorization mode. In this mode, Kubelet sends a `SubjectAccessReview` to the API server to check if the identity is authorized to perform the required action. Configure the Kubernetes RBAC such as only service accounts that should legitimacy communicate with Kubelet API have the relevant permissions.| 23 | |[MS-M9027](../mitigations/MS-M9027%20Use%20NodeRestriction%20Admission%20Controller.md)|Use NodeRestriction Admission Controller|Limit Kubelet permissions to pods and nodes| -------------------------------------------------------------------------------- /docs/techniques/Access cloud resources.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Access cloud resources 8 | 9 | !!! info inline end 10 | ID: MS-TA9020
11 | Tactic: [Privilege Escalation](../tactics/PrivilegeEscalation/index.md), [Lateral Movement](../tactics/LateralMovement/index.md)
12 | MITRE technique: [T1078.004](https://attack.mitre.org/techniques/T1078/004/) 13 | 14 | If the Kubernetes cluster is deployed in the cloud, in some cases attackers can leverage their access to a single container to get access to other cloud resources outside the cluster. For example, AKS uses several managed identities that are attached to the nodes, for the cluster operation. Similar identities exist also in EKS and GKE (EC2 roles and IAM service accounts, respectively). By default, running pods can retrieve the identities which in some configurations have privileged permissions. Therefore, if attackers gain access to a running pod in the cluster, they can leverage the identities to access external cloud resources. 15 | 16 | Also, AKS has an option to authenticate with Azure using a service principal. When this option is enabled, each node stores service principal credentials that are located in /etc/kubernetes/azure.json. AKS uses this service principal to create and manage Azure resources that are needed for the cluster operation. By default, the service principal has contributor permissions in the cluster’s Resource Group. Attackers who get access to this service principal file (by hostPath mount, for example) can use its credentials to access or modify the cloud resources. 17 | 18 | 19 | ## Mitigations 20 | 21 | |ID|Mitigation|Description| 22 | |--|----------|-----------| 23 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Grant only necessary permission to the cloud identities.| 24 | |[MS-M9018](../mitigations/MS-M9018%20Restricting%20cloud%20metadata%20API%20access.md)|Restrict the access of pods to IMDS|Restrict the access of pods to IMDS to restrict pods from getting access to cloud identities.| 25 | |[MS-M9019](../mitigations/MS-M9019%20Allocate%20specific%20identities%20to%20pods.md)|Allocate specific identities to pods|Use dedicated allocated identities to pods| 26 | |[MS-M9013](../mitigations/MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers|Block mounting volumes with access to cloud credentials.| -------------------------------------------------------------------------------- /docs/techniques/Access managed identity credentials.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Access Managed Identity credentials 8 | 9 | !!! info inline end 10 | ID: MS-TA9028
11 | Tactic: [Credential Access](../tactics/CredentialAccess/index.md)
12 | MITRE technique: [T1552.005](https://attack.mitre.org/techniques/T1552/005/) 13 | 14 | Managed identities are identities that are managed by the cloud provider and can be allocated to cloud resources, such as virtual machines. Those identities are used to authenticate with cloud services. The identity’s secret is fully managed by the cloud provider, which eliminates the need to manage the credentials. Applications can obtain the identity’s token by accessing the Instance Metadata Service (IMDS). Attackers who get access to a Kubernetes pod can leverage their access to the IMDS endpoint to get the managed identity’s token. With a token, the attackers can access cloud resources. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9018](../mitigations/MS-M9018%20Restricting%20cloud%20metadata%20API%20access.md)|Restricting cloud metadata API access|Restrict the access of pods to IMDS| 21 | |[MS-M9019](../mitigations/MS-M9019%20Allocate%20specific%20identities%20to%20pods.md)|Allocate specific identities to pods|Allocate specific identities to pods.| -------------------------------------------------------------------------------- /docs/techniques/Access the K8S API server.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Access Kubernetes API server 8 | 9 | !!! info inline end 10 | ID: MS-TA9029
11 | Tactic: [Discovery](../tactics/Discovery/index.md)
12 | MITRE technique: [T1613](https://attack.mitre.org/techniques/T1613/) 13 | 14 | The Kubernetes API server is the gateway to the cluster. Actions in the cluster are performed by sending various requests to the RESTful API. The status of the cluster, which includes all the components that are deployed on it, can be retrieved by the API server. Attackers may send API requests to probe the cluster and get information about containers, secrets, and other resources in the cluster. 15 | 16 | In addition, the Kubernetes API server can also be used to query information about Role Based Access (RBAC) information such as Roles, ClusterRoles, RoleBinding, ClusterRoleBinding and Service Accounts. Attacker may use this information to discover permissions and access associated with Service Accounts in the cluster and use this information to progress towards its attack objectives. 17 | 18 | ## Mitigations 19 | 20 | |ID|Mitigation|Description| 21 | |--|----------|-----------| 22 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Configure the Kubernetes RBAC such as each service account has only the minimal necessary permissions for the application’s functionality.| 23 | |[MS-M9002](../mitigations/MS-M9002%20Restrict%20access%20to%20the%20API%20server%20using%20IP%20firewall.md)|Restrict access to the API server using IP firewall|Restrict access of cloud accounts to API server from trusted IP addresses only.| 24 | -------------------------------------------------------------------------------- /docs/techniques/Application Exploit (RCE).md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Application exploit (RCE) 8 | 9 | !!! info inline end 10 | ID: MS-TA9009
11 | Tactic: [Execution](../tactics/Execution/index.md)
12 | MITRE technique: [T1190](https://attack.mitre.org/techniques/T1190/) 13 | 14 | An application that is deployed in the cluster and is vulnerable to a remote code execution vulnerability, or a vulnerability that eventually allows code execution, enables attackers to run code in the cluster. If service account is mounted to the container (default behavior in Kubernetes), the attacker will be able to send requests to the API server using this service account credentials. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9005](../mitigations/MS-M9005/index.md)|Image Assurance Policy|Block vulnerable images| 21 | |[MS-M9014](../mitigations/MS-M9014%20Network%20Segmentation.md)|Network Segmentation|Limit network access to containers| 22 | |[MS-M9011](../mitigations/MS-M9011%20Restrict%20Container%20Runtime%20using%20LSM.md)|Restrict Container Runtime using LSM|Restrict container runtime capabilities using LSM.| -------------------------------------------------------------------------------- /docs/techniques/Application Vulnerability.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Application vulnerability 8 | 9 | !!! info inline end 10 | ID: MS-TA9004
11 | Tactic: [Initial Access](../tactics/InitialAccess/index.md)
12 | MITRE technique: [T1190](https://attack.mitre.org/techniques/T1190/) 13 | 14 | Running a public-facing vulnerable application in a cluster can enable initial access to the cluster. A container that runs an application that is vulnerable to remote code execution vulnerability (RCE) may be exploited. If service account is mounted to the container (default behavior in Kubernetes), the attacker will be able to send requests to the API server using this service account credentials. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9005](../mitigations/MS-M9005/index.md)|Image Assurance Policy|Ensure that only images that passed the security compliance policies are pushed to registries and deployed to Kubernetes clusters.| 21 | |[MS-M9007](../mitigations/MS-M9007%20Network%20Intrusion%20Prevention.md)|Network Intrusion Prevention|Use network intrusion prevention to block exploiting vulnerabilities.| -------------------------------------------------------------------------------- /docs/techniques/Application credentials in configuration files.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Application credentials in configuration files 8 | 9 | !!! info inline end 10 | ID: MS-TA9027
11 | Tactic: [Credential Access](../tactics/CredentialAccess/index.md), [Lateral Movement](../tactics/LateralMovement/index.md)
12 | MITRE technique: [T1552](https://attack.mitre.org/techniques/T1552/) 13 | 14 | Developers store secrets in the Kubernetes configuration files, such as environment variables in the pod configuration. Such behavior is commonly seen in clusters that are monitored by Microsoft Defender for Cloud. Attackers who have access to those configurations, by querying the API server or by accessing those files on the developer’s endpoint, can steal the stored secrets and use them. 15 | 16 | Using those credentials attackers may gain access to additional resources inside and outside the cluster. 17 | 18 | ## Mitigations 19 | 20 | |ID|Mitigation|Description| 21 | |--|----------|-----------| 22 | |[MS-M9026](../mitigations/MS-M9026%20Avoid%20using%20plain%20text%20credentials%20in%20configuration%20files.md)|Avoid using plain text credentials|Avoid using plain text credentials in Kubernetes configuration| 23 | |[MS-M9022](../mitigations/MS-M9022%20Use%20Managed%20Secret%20Store.md)|Use Managed Secret Store|Store secrets securely in managed secret stores| -------------------------------------------------------------------------------- /docs/techniques/Backdoor container.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Backdoor container 8 | 9 | !!! info inline end 10 | ID: MS-TA9012
11 | Tactic: [Persistence](../tactics/Persistence/index.md)
12 | MITRE technique: [T1543](https://attack.mitre.org/techniques/T1543/) 13 | 14 | Attackers run their malicious code in a container in the cluster. By using the Kubernetes controllers such as DaemonSets or Deployments, attackers can ensure that a constant number of containers run in one, or all, the nodes in the cluster. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Prevent unnecessary users and service accounts from creating new pods and controllers.| 21 | |[MS-M9013](../mitigations/MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers|Restrict over permissive containers in the cluster using admission controller.| 22 | |[MS-M9005.003](../mitigations/MS-M9005/MS-M9005.003%20Gate%20images%20deployed%20to%20Kubenertes%20cluster.md)|Gate images deployed to Kubernetes cluster|Restrict deployment of new containers from trusted supply chain| -------------------------------------------------------------------------------- /docs/techniques/Clear container logs.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Clear container logs 8 | 9 | !!! info inline end 10 | ID: MS-TA9021
11 | Tactic: [Defense Evasion](../tactics/DefenseEvasion/index.md)
12 | MITRE technique: [T1070](https://attack.mitre.org/techniques/T1070/) 13 | 14 | Attackers may delete the application or OS logs on a compromised container in an attempt to prevent detection of their activity. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9020](../mitigations/MS-M9020%20Collect%20Logs%20to%20Remote%20Data%20Storage.md)|Collect Logs to Remote Data Storage|Collect container logs to a separate storage system.| 21 | |[MS-M9016](../mitigations/MS-M9016%20Restrict%20File%20and%20Directory%20Permissions.md)|Restrict File and Directory Permissions|Restrict access to container logs.| -------------------------------------------------------------------------------- /docs/techniques/Cluster internal networking.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Cluster internal networking 8 | 9 | !!! info inline end 10 | ID: MS-TA9034
11 | Tactic: [Lateral Movement](../tactics/LateralMovement/index.md)
12 | MITRE technique: [T1210](https://attack.mitre.org/techniques/T1210/) 13 | 14 | Kubernetes networking behavior allows traffic between pods in the cluster as a default behavior. Attackers who gain access to a single container may use it for network reachability to another container in the cluster. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9014](../mitigations/MS-M9014%20Network%20Segmentation.md)|Network Segmentation|Provision pod network policies to restrict the traffic between pods| 21 | |[MS-M9005](../mitigations/MS-M9005/index.md)|Image Assurance Policy|Avoid deployment of vulnerable applications to the cluster| -------------------------------------------------------------------------------- /docs/techniques/Cluster-admin binding.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Cluster-admin binding 8 | 9 | !!! info inline end 10 | ID: MS-TA9019
11 | Tactic: [Privilege Escalation](../tactics/PrivilegeEscalation/index.md)
12 | MITRE technique: [T1078.003](https://attack.mitre.org/techniques/T1078/003/) 13 | 14 | Role-based access control (RBAC) is a key security feature in Kubernetes. RBAC can restrict the allowed actions of the various identities in the cluster. Cluster-admin is a built-in high privileged role in Kubernetes. Attackers who have permissions to create bindings and cluster-bindings in the cluster can create a binding to the cluster-admin ClusterRole or to other high privileges roles. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Review privileged role binding and RBAC settings, restrict permissions to configure `rolebinding` and `clusterrolebinding`.| -------------------------------------------------------------------------------- /docs/techniques/Collecting Data from Pod.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Collecting data from pod 8 | 9 | !!! info inline end 10 | ID: MS-TA9041
11 | Tactic: [Collection](../tactics/Collection/index.md)
12 | MITRE technique: 13 | 14 | 15 | Using Kubernetes administrative commands an attacker can collect information from a pod without having to get direct access to that pod. One example of such a command is `kubectl cp` which can be used to copy files to and from pods. 16 | 17 | Another example is Kubelet Checkpoint API which can be used to create a stateful copy of a running container. Typically a checkpoint contains all memory pages of all processes in the checkpoint container. This means that everything that used to be in memory is now available on the local disk. This includes all private data and possibly keys used for encryption. 18 | 19 | 20 | ## Mitigations 21 | 22 | |ID|Mitigation|Description| 23 | |--|----------|-----------| 24 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Adhere to least-privilege principle to prevent users from checkpoint or running kubectl cp commands. `kubectl cp` wraps exec command which runs a tar process. Preventing exec into a container would effectively restrict `kubectl cp` command.| 25 | |[MS-M9010](../mitigations/MS-M9010%20Restrict%20Exec%20Commands%20on%20Pods.md)|Restrict Exec Commands on Pods|Restrict checkpoint and other commands on pods using admissions controller.| -------------------------------------------------------------------------------- /docs/techniques/Compromised Image In Registry.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Compromised image In registry 8 | 9 | !!! info inline end 10 | ID: MS-TA9002
11 | Tactic: [Initial Access](../tactics/InitialAccess/index.md)
12 | MITRE technique: [T1195.002](https://attack.mitre.org/techniques/T1195/002/), [T1525](https://attack.mitre.org/techniques/T1525/) 13 | 14 | Running a compromised image in a cluster can compromise the cluster. Attackers who get access to a private registry can plant their own compromised images in the registry. The latter can then be pulled by a user. In addition, users often use untrusted images from public registries (such as Docker Hub) that may be malicious. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9004](../mitigations/MS-M9004%20Secure%20CI%20CD%20environment.md)|Secure CI/CD environment|Placing gates in the CI\CD process can block pushing unsecured code to container images.| 21 | |[MS-M9005](../mitigations/MS-M9005/index.md)|Image Assurance Policy|Ensure that only images that passed the security compliance policies are pushed to registries and deployed to Kubernetes clusters.| -------------------------------------------------------------------------------- /docs/techniques/Connect from Proxy server.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Connect from proxy server 8 | 9 | !!! info inline end 10 | ID: MS-TA9024
11 | Tactic: [Defense Evasion](../tactics/DefenseEvasion/index.md)
12 | MITRE technique: [T1090](https://attack.mitre.org/techniques/T1090/) 13 | 14 | Attackers may use proxy servers to hide their origin IP. Specifically, attackers often use anonymous networks such as TOR for their activity. This can be used for communicating with the applications themselves or with the API server. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9002](../mitigations/MS-M9002%20Restrict%20access%20to%20the%20API%20server%20using%20IP%20firewall.md)|Restrict access to the API server using IP firewall|Restrict access to the API server from known IP addresses| 21 | |[MS-M9014](../mitigations/MS-M9014%20Network%20Segmentation.md)|Network Segmentation|Limit network access from known proxy networks.| 22 | |[MS-M9021](../mitigations/MS-M9021%20Restrict%20the%20usage%20of%20unauthenticated%20APIs%20in%20the%20Cluster.md)|Restrict the usage of unauthenticated APIs in the cluster|Restrict unauthenticated API to the Kubernetes API server.| 23 | |[MS-M9009](../mitigations/MS-M9009%20Require%20Strong%20Authentication%20to%20Services.md)|Require Strong Authentication to Services|Limit usage of kubeconfig authentication to the API server| 24 | -------------------------------------------------------------------------------- /docs/techniques/CoreDNS poisoning.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # CoreDNS poisoning 8 | 9 | !!! info inline end 10 | ID: MS-TA9035
11 | Tactic: [Lateral Movement](../tactics/LateralMovement/index.md)
12 | MITRE technique: [T1557](https://attack.mitre.org/techniques/T1557/) 13 | 14 | CoreDNS is a modular Domain Name System (DNS) server written in Go, hosted by Cloud Native Computing Foundation (CNCF). CoreDNS is the main DNS service that is being used in Kubernetes. The configuration of CoreDNS can be modified by a file named corefile. In Kubernetes, this file is stored in a ConfigMap object, located at the kube-system namespace. If attackers have permissions to modify the ConfigMap, for example by using the container’s service account, they can change the behavior of the cluster’s DNS, poison it, and take the network identity of other services. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Limit updates permissions to the CoreDNS ConfigMap object.| -------------------------------------------------------------------------------- /docs/techniques/Data destruction.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Data destruction 8 | 9 | !!! info inline end 10 | ID: MS-TA9038
11 | Tactic: [Impact](../tactics/Impact/index.md)
12 | MITRE technique: [T1485](https://attack.mitre.org/techniques/T1485/) 13 | 14 | Attackers may attempt to destroy data and resources in the cluster. This includes deleting deployments, configurations, storage, and compute resources. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9030](../mitigations/MS-M9030%20Use%20Cloud%20Storage%20Provider.md)|Use Cloud Storage Provider|Use Cloud Storage provider to persist application data.| 21 | |[MS-M9031](../mitigations/MS-M9031%20Implement%20Data%20Backup%20Strategy.md)|Implement Data Backup Strategy|Backup pod mounted volumes for critical workloads.| -------------------------------------------------------------------------------- /docs/techniques/Delete K8S events.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Delete Kubernetes events 8 | 9 | !!! info inline end 10 | ID: MS-TA9022
11 | Tactic: [Defense Evasion](../tactics/DefenseEvasion/index.md)
12 | MITRE technique: [T1070](https://attack.mitre.org/techniques/T1070/) 13 | 14 | A Kubernetes event is a Kubernetes object that logs state changes and failures of the resources in the cluster. Example events are a container creation, an image pull, or a pod scheduling on a node. 15 | 16 | Kubernetes events can be very useful for identifying changes that occur in the cluster. Therefore, attackers may want to delete these events (e.g., by using: “kubectl delete events–all”) in an attempt to avoid detection of their activity in the cluster. 17 | 18 | ## Mitigations 19 | 20 | |ID|Mitigation|Description| 21 | |--|----------|-----------| 22 | |[MS-M9020](../mitigations/MS-M9020%20Collect%20Logs%20to%20Remote%20Data%20Storage.md)|Collect Logs to Remote Data Storage|Collect Kubernetes logs to a separate storage system.| 23 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Restrict permissions to delete Kubernetes events.| -------------------------------------------------------------------------------- /docs/techniques/Denial of service.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Denial of service 8 | 9 | !!! info inline end 10 | ID: MS-TA9040
11 | Tactic: [Impact](../tactics/Impact/index.md)
12 | MITRE technique: [T1498](https://attack.mitre.org/techniques/T1498/), [T1499](https://attack.mitre.org/techniques/T1499/) 13 | 14 | Attackers may attempt to perform a denial of service attack, which makes the service unavailable to the legitimate users. In container clusters, this include attempts to block the availability of the containers themselves, the underlying nodes, or the API server. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9011](../mitigations/MS-M9011%20Restrict%20Container%20Runtime%20using%20LSM.md)|Restrict Container Runtime using LSM|Restrict execution of unwanted processes in containers.| 21 | |[MS-M9002](../mitigations/MS-M9002%20Restrict%20access%20to%20the%20API%20server%20using%20IP%20firewall.md)|Restrict access to the API server using IP firewall|Restrict access to the API server from known IP addresses.| 22 | |[MS-M9029](../mitigations/MS-M9029%20Set%20requests%20and%20limits%20for%20containers.md)|Set requests and limits for containers|Limit compute resources for containers.| -------------------------------------------------------------------------------- /docs/techniques/Exec into container.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Exec into container 8 | 9 | !!! info inline end 10 | ID: MS-TA9006
11 | Tactic: [Execution](../tactics/Execution/index.md)
12 | MITRE technique: [T1609](https://attack.mitre.org/techniques/T1609/) 13 | 14 | Attackers who have permissions, can run malicious commands in containers in the cluster using exec command (“kubectl exec”). In this method, attackers can use legitimate images, such as an OS image (e.g., Ubuntu) as a backdoor container, and run their malicious code remotely by using “kubectl exec”. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Adhere to least-privilege principle to prevent users from exec into containers| 21 | |[MS-M9010](../mitigations/MS-M9010%20Restrict%20Exec%20Commands%20on%20Pods.md)|Restrict Exec Commands on Pods|Restrict exec commands on pods using admissions controller.| 22 | |[MS-M9011](../mitigations/MS-M9011%20Restrict%20Container%20Runtime%20using%20LSM.md)|Restrict Container Runtime using LSM|Restrict container runtime capabilities using LSM.| -------------------------------------------------------------------------------- /docs/techniques/Exposed sensitive interfaces.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Exposed sensitive interfaces 8 | 9 | !!! info inline end 10 | ID: MS-TA9005
11 | Tactic: [Initial Access](../tactics/InitialAccess/index.md), [Discovery](../tactics/Discovery/index.md)
12 | MITRE technique: [T1133](https://attack.mitre.org/techniques/T1133/) 13 | 14 | Exposing a sensitive interface to the internet or within a cluster without strong authentication poses a security risk. Some popular cluster management services were not intended to be exposed to the internet, and therefore don’t require authentication by default. Thus, exposing such services to the internet allows unauthenticated access to a sensitive interface which might enable running code or deploying containers in the cluster by a malicious actor. Examples of such interfaces that were seen exploited include Apache NiFi, Kubeflow, Argo Workflows, Weave Scope, and the Kubernetes dashboard. 15 | 16 | In addition, having such services exposed within the cluster network without strong authentication can also allow an attacker to collect information about other workloads deployed to the cluster. 17 | The Kubernetes dashboard is an example of such a service that is used for monitoring and managing the Kubernetes cluster. The dashboard allows users to perform actions in the cluster using its service account (kubernetes-dashboard) with permissions that are determined by the binding or cluster-binding for this service account. Attackers who gain access to a container in the cluster, can use its network access to the dashboard pod. Consequently, attackers may retrieve information about the various resources in the cluster using the dashboard’s identity. 18 | 19 | 20 | ## Mitigations 21 | 22 | |ID|Mitigation|Description| 23 | |--|----------|-----------| 24 | |[MS-M9008](../mitigations/MS-M9008%20Limit%20Access%20to%20Services%20Over%20Network.md)|Limit Access to Services Over Network|Limit access to sensitive interface over the Internet| 25 | |[MS-M9009](../mitigations/MS-M9009%20Require%20Strong%20Authentication%20to%20Services.md)|Require Strong Authentication to Services|Require strong authentication to exposed services| 26 | |[MS-M9014](../mitigations/MS-M9014%20Network%20Segmentation.md)|Network Segmentation|Restrict network access to the sensitive interfaces.| -------------------------------------------------------------------------------- /docs/techniques/Instance Metadata API.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Instance Metadata API 8 | 9 | !!! info inline end 10 | ID: MS-TA9033
11 | Tactic: [Discovery](../tactics/Discovery/index.md)
12 | MITRE technique: [T1552.005](https://attack.mitre.org/techniques/T1552/005/) 13 | 14 | Cloud providers provide instance metadata service for retrieving information about the virtual machine, such as network configuration, disks, and SSH public keys. This service is accessible to the VMs via a non-routable IP address that can be accessed from within the VM only. Attackers who gain access to a container, may query the metadata API service for getting information about the underlying node. For example, in Azure, the following request would retrieve all the metadata information of an instance: http:///metadata/instance?api-version=2019-06-01 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9018](../mitigations/MS-M9018%20Restricting%20cloud%20metadata%20API%20access.md)|Restricting cloud metadata API access|Restrict the access of pods to IMDS| -------------------------------------------------------------------------------- /docs/techniques/Kubeconfig file.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Kubeconfig file 8 | 9 | !!! info inline end 10 | ID: MS-TA9003
11 | Tactic: [Initial Access](../tactics/InitialAccess/index.md)
12 | MITRE technique: 13 | 14 | The kubeconfig file, also used by kubectl, contains details about Kubernetes clusters including their location and credentials. If the cluster is hosted as a cloud service (such as AKS or GKE), this file is downloaded to the client via cloud commands (e.g., `az aks get-credential` for AKS or `gcloud container clusters get-credentials` for GKE). 15 | 16 | 17 | If attackers get access to this file, for instance via a compromised client, they can use it for accessing the clusters. 18 | 19 | ## Mitigations 20 | 21 | |ID|Mitigation|Description| 22 | |--|----------|-----------| 23 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Limit privileges and actions that can be achieved by getting access to a kubeconfig file| 24 | |[MS-M9002](../mitigations/MS-M9002%20Restrict%20access%20to%20the%20API%20server%20using%20IP%20firewall.md)|Restrict access to the API server using IP firewall|Restrict access to the API server from known IP addresses| 25 | |[MS-M9006](../mitigations/MS-M9006%20Enable%20Just%20In%20Time%20access%20to%20API%20server.md)|Enable Just In Time access to API server|Enable JIT elevated access to API server to limit attack surface or impact.| 26 | -------------------------------------------------------------------------------- /docs/techniques/Kubernetes CronJob.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Kubernetes CronJob 8 | 9 | !!! info inline end 10 | ID: MS-TA9014
11 | Tactic: [Persistence](../tactics/Persistence/index.md)
12 | MITRE technique: [T1053.007](https://attack.mitre.org/techniques/T1053/007/) 13 | 14 | Kubernetes Job is a controller that creates one or more pods and ensures that a specified number of them successfully terminate. Kubernetes Job can be used to run containers that perform finite tasks for batch jobs. Kubernetes CronJob is used to schedule Jobs. Attackers may use Kubernetes CronJob for scheduling execution of malicious code that would run as a container in the cluster. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9005.003](../mitigations/MS-M9005/index.md)|Gate images deployed to Kubernetes cluster|Restrict deployment of new containers from trusted supply chain| 21 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Prevent unnecessary users and service accounts from creating new cronjobs.| 22 | |[MS-M9013](../mitigations/MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers|Check cronjob pod template for sensitive mounts and excessive permissions.| -------------------------------------------------------------------------------- /docs/techniques/List K8S secrets.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # List Kubernetes secrets 8 | 9 | !!! info inline end 10 | ID: MS-TA9025
11 | Tactic: [Credential Access](../tactics/CredentialAccess/index.md)
12 | MITRE technique: [T1552.007](https://attack.mitre.org/techniques/T1552/007/) 13 | 14 | A Kubernetes secret is an object that lets users store and manage sensitive information, such as passwords and connection strings in the cluster. Secrets can be consumed by reference in the pod configuration. Attackers who have permissions to retrieve the secrets from the API server (by using the pod service account, for example) can access sensitive information that might include credentials to various services. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Limit users and service accounts access to Kubernetes secrets.| 21 | |[MS-M9022](../mitigations/MS-M9022%20Use%20Managed%20Secret%20Store.md)|Use Managed Secret Store|Use cloud provider secret store to securely manage credentials in the cluster| 22 | |[MS-M9023](../mitigations/MS-M9023%20Remove%20unused%20secrets%20from%20the%20cluster.md)|Remove unused secrets objects from the cluster|Remove unused secrets from the cluster.| 23 | |[MS-M9024](../mitigations/MS-M9024%20Restrict%20access%20to%20etcd.md)|Restrict access to etcd|Restrict access to etcd.| -------------------------------------------------------------------------------- /docs/techniques/Malicious admission controller.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Malicious admission controller 8 | 9 | !!! info inline end 10 | ID: MS-TA9015
11 | Tactic: [Persistence](../tactics/Persistence/index.md), [Credential Access](../tactics/CredentialAccess/index.md)
12 | MITRE technique: [T1546](https://attack.mitre.org/techniques/T1546/) 13 | 14 | Admission controller is a Kubernetes component that intercepts, and possibly modifies, requests to the Kubernetes API server. There are two types of admissions controllers: validating and mutating controllers. As the name implies, a mutating admission controller can modify the intercepted request and change its properties. Kubernetes has a built-in generic admission controller named MutatingAdmissionWebhook. The behavior of this admission controller is determined by an admission webhook that the user deploys in the cluster. Attackers can use such webhooks for gaining persistence in the cluster. For example, attackers can intercept and modify the pod creation operations in the cluster and add their malicious container to every created pod. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Restrict permissions to deploy or modify `MutatingAdmissionWebhook` and `ValidatingAdmissionWebhook` objects.| -------------------------------------------------------------------------------- /docs/techniques/Mount service principal.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Mount service principal 8 | 9 | !!! info inline end 10 | ID: MS-TA9026
11 | Tactic: [Credential Access](../tactics/CredentialAccess/index.md)
12 | MITRE technique: [T1552.001](https://attack.mitre.org/techniques/T1552/001/) 13 | 14 | When the cluster is deployed in the cloud, in some cases attackers can leverage their access to a container in the cluster to gain cloud credentials. For example, in AKS each node contains service principal credential. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9013](../mitigations/MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers|Block sensitive volume mounts using admission controller| 21 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Grant minimal required permissions to service principals| -------------------------------------------------------------------------------- /docs/techniques/Network mapping.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Network mapping 8 | 9 | !!! info inline end 10 | ID: MS-TA9031
11 | Tactic: [Discovery](../tactics/Discovery/index.md)
12 | MITRE technique: [T1046](https://attack.mitre.org/techniques/T1046/) 13 | 14 | Attackers may try to map the cluster network to get information on the running applications, including scanning for known vulnerabilities. By default, there is no restriction on pods communication in Kubernetes. Therefore, attackers who gain access to a single container, may use it to probe the network. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9014](../mitigations/MS-M9014%20Network%20Segmentation.md)|Network Segmentation|Restrict network between pods using network policies| -------------------------------------------------------------------------------- /docs/techniques/New Container.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # New container 8 | 9 | !!! info inline end 10 | ID: MS-TA9008
11 | Tactic: [Execution](../tactics/Execution/index.md)
12 | MITRE technique: [T1610](https://attack.mitre.org/techniques/T1610/) 13 | 14 | Attackers may attempt to run their code in the cluster by deploying a container. Attackers who have permissions to deploy a pod or a controller in the cluster (such as DaemonSet \ ReplicaSet\ Deployment) can create a new resource for running their code. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Prevent unnecessary users and service accounts from creating new pods and controllers.| 21 | |[MS-M9013](../mitigations/MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers|Restrict over permissive containers in the cluster using admission controller.| 22 | |[MS-M9005.003](../mitigations/MS-M9005/MS-M9005.003%20Gate%20images%20deployed%20to%20Kubenertes%20cluster.md)|Gate images deployed to Kubenertes cluster|Restrict deployment of new containers from trusted supply chain| -------------------------------------------------------------------------------- /docs/techniques/Pod or container name similarily.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Pod or container name similarity 8 | 9 | !!! info inline end 10 | ID: MS-TA9023
11 | Tactic: [Defense Evasion](../tactics/DefenseEvasion/index.md)
12 | MITRE technique: [T1036.005](https://attack.mitre.org/techniques/T1036/005/) 13 | 14 | Pods that are created by controllers such as Deployment or DaemonSet have random suffix in their names. Attackers can use this fact and name their backdoor pods as they were created by the existing controllers. For example, an attacker could create a malicious pod named coredns-{random suffix} which would look related to the CoreDNS Deployment. 15 | 16 | Also, attackers can deploy their containers in the kube-system namespace where the administrative containers reside. 17 | 18 | ## Mitigations 19 | 20 | |ID|Mitigation|Description| 21 | |--|----------|-----------| 22 | |[MS-M9005.003](../mitigations/MS-M9005/MS-M9005.003%20Gate%20images%20deployed%20to%20Kubenertes%20cluster.md)|Gate images deployed to Kubernetes cluster|Restrict deployment of new containers from trusted supply chain| 23 | -------------------------------------------------------------------------------- /docs/techniques/Privileged container.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Privileged container 8 | 9 | !!! info inline end 10 | ID: MS-TA9018
11 | Tactic: [Privilege Escalation](../tactics/PrivilegeEscalation/index.md)
12 | MITRE technique: [T1610](https://attack.mitre.org/techniques/T1610/) 13 | 14 | A privileged container is a container that has all the capabilities of the host machine, which lifts all the limitations regular containers have. Practically, this means that privileged containers can do almost every action that can be performed directly on the host. Attackers who gain access to a privileged container, or have permissions to create a new privileged container (by using the compromised pod’s service account, for example), can get access to the host’s resources. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9013](../mitigations/MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers|Block privileged containers using admission controller.| 21 | |[MS-M9017](../mitigations/MS-M9017%20Ensure%20that%20pods%20meet%20defined%20Pod%20Security%20Standards.md)|Ensure that pods meet defined Pod Security Standards|Restrict privileged containers using pod security standards.| 22 | |[MS-M9005.003](../mitigations/MS-M9005/index.md)|Gate images deployed to Kubernetes cluster|Restrict deployment of new containers from trusted supply chain| -------------------------------------------------------------------------------- /docs/techniques/Resource hijacking.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Resource hijacking 8 | 9 | !!! info inline end 10 | ID: MS-TA9039
11 | Tactic: [Impact](../tactics/Impact/index.md)
12 | MITRE technique: [T1496](https://attack.mitre.org/techniques/T1496/) 13 | 14 | Attackers may abuse a compromised resource for running tasks. A common abuse is to use compromised resources for running digital currency mining. Attackers who have access to a container in the cluster or have permissions to create new containers may use them for such activity. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9011](../mitigations/MS-M9011%20Restrict%20Container%20Runtime%20using%20LSM.md)|Restrict Container Runtime using LSM|Restrict execution of unwanted processes in containers.| 21 | |[MS-M9012](../mitigations/MS-M9012%20Remove%20Tools%20from%20Container%20Images.md)|Remove Tools from Container Images|Remove unused tools from the container image.| -------------------------------------------------------------------------------- /docs/techniques/SSH server running inside container.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # SSH server running inside container 8 | 9 | !!! info inline end 10 | ID: MS-TA9010
11 | Tactic: [Execution](../tactics/Execution/index.md)
12 | MITRE technique: 13 | 14 | SSH server that is running inside a container may be used by attackers. If attackers gain valid credentials to a container, whether by brute force attempts or by other methods (such as phishing), they can use it to get remote access to the container by SSH. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9015](../mitigations/MS-M9015%20Avoid%20Running%20Management%20Interface%20on%20Containers.md)|Avoid Running Management Interface on Containers|Avoid running SSH daemon on containers| 21 | |[MS-M9014](../mitigations/MS-M9014%20Network%20Segmentation.md)|Network Segmentation|Limit network access to containers| 22 | |[MS-M9011](../mitigations/MS-M9011%20Restrict%20Container%20Runtime%20using%20LSM.md)|Restrict Container Runtime using LSM|Limit which process can open network socket on a container.| -------------------------------------------------------------------------------- /docs/techniques/Sidecar Injection.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Sidecar injection 8 | 9 | !!! info inline end 10 | ID: MS-TA9011
11 | Tactic: [Execution](../tactics/Execution/index.md)
12 | MITRE technique: [T1610](https://attack.mitre.org/techniques/T1610/) 13 | 14 | A Kubernetes Pod is a group of one or more containers with shared storage and network resources. Sidecar container is a term that is used to describe an additional container that resides alongside the main container. For example, service-mesh proxies are operating as sidecars in the applications’ pods. Attackers can run their code and hide their activity by injecting a sidecar container to a legitimate pod in the cluster instead of running their own separated pod in the cluster. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Prevent unnecessary users and service accounts from creating new pods and controllers.| 21 | |[MS-M9013](../mitigations/MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers|Restrict over permissive containers in the cluster using admission controller.| 22 | |[MS-M9005.003](../mitigations/MS-M9005/MS-M9005.003%20Gate%20images%20deployed%20to%20Kubenertes%20cluster.md)|Gate images deployed to Kubernetes cluster|Restrict deployment of new containers from trusted supply chain| -------------------------------------------------------------------------------- /docs/techniques/Static Pods.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Static pods 8 | 9 | !!! info inline end 10 | ID: MS-TA9017
11 | Tactic: [Persistence](../tactics/Persistence/index.md)
12 | MITRE technique: 13 | 14 | Static Pods are created and managed by the the kubelet daemon on each node, without the API server observing them. Kubelet watches each static pod and restart it if it fails. 15 | 16 | Kubelet automatically tries to create a mirror pod on the Kubernetes API server to represent the static pods, so it will be visible on the API server, however the pods cannot be controlled from there. 17 | 18 | Static Pods are created based on a web or local filesystem YAML files which kubelet observes for changes. 19 | An attacker can use the static pods manifest file to ensure that a pod is always running on a cluster node and prevent it from being changed or deleted from the Kubernetes API server. 20 | 21 | 22 | ## Mitigations 23 | 24 | |ID|Mitigation|Description| 25 | |--|----------|-----------| 26 | |[MS-M9016](../mitigations/MS-M9016%20Restrict%20File%20and%20Directory%20Permissions.md)|Restrict File and Directory Permissions|Restrict write access to the static pods manifest folder.| 27 | |[MS-M9032](../mitigations/MS-M9032%20Avoid%20using%20web-hosted%20manifest%20for%20Kubelet.md)|Avoid using web-hosted manifest for Kubelet|Avoid using web-hosted manifest for Kubelet.| -------------------------------------------------------------------------------- /docs/techniques/Using Cloud Credentials.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Using cloud credentials 8 | 9 | !!! info inline end 10 | ID: MS-TA9001
11 | Tactic: [Initial Access](../tactics/InitialAccess/index.md)
12 | MITRE technique: [T1078.004](https://attack.mitre.org/techniques/T1078/004/) 13 | 14 | In cases where the Kubernetes cluster is deployed in a public cloud (e.g., AKS in Azure, GKE in GCP, or EKS in AWS), compromised cloud credential can lead to cluster takeover. Attackers who have access to the cloud account credentials can get access to the cluster’s management layer. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9001](../mitigations/MS-M9001%20Multi-factor%20Authentication.md)|Multi-factor Authentication|Use multi-factor authentication for cloud accounts which can be elevated to access Kubernetes clusters in that cloud.| 21 | |[MS-M9002](../mitigations/MS-M9002%20Restrict%20access%20to%20the%20API%20server%20using%20IP%20firewall.md)|Restrict access to the API server using IP firewall|Restrict access of cloud accounts to API server from trusted IP addresses only.| 22 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Limit RBAC privileges in the cloud account to retrieve access credentials to managed Kubernetes clusters.| -------------------------------------------------------------------------------- /docs/techniques/Writable hostPath mount.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Writable hostPath mount 8 | 9 | !!! info inline end 10 | ID: MS-TA9013
11 | Tactic: [Persistence](../tactics/Persistence/index.md), [Privilege Escalation](../tactics/PrivilegeEscalation/index.md), [Lateral Movement](../tactics/LateralMovement/index.md)
12 | MITRE technique: [T1611](https://attack.mitre.org/techniques/T1611/) 13 | 14 | hostPath volume mounts a directory or a file from the host to the container. Attackers who have permissions to create a new container in the cluster may create one with a writable hostPath volume and gain persistence on the underlying host. For example, the latter can be achieved by creating a cron job on the host. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9013](../mitigations/MS-M9013%20Restrict%20over%20permissive%20containers.md)|Restrict over permissive containers|Block sensitive volume mounts using admission controller.| 21 | |[MS-M9016](../mitigations/MS-M9016%20Restrict%20File%20and%20Directory%20Permissions.md)|Restrict File and Directory Permissions|Use read-only volumes.| 22 | |[MS-M9011](../mitigations/MS-M9011%20Restrict%20Container%20Runtime%20using%20LSM.md)|Restrict Container Runtime using LSM|Use AppArmor to restrict file writing.| 23 | |[MS-M9017](../mitigations/MS-M9017%20Ensure%20that%20pods%20meet%20defined%20Pod%20Security%20Standards.md)|Ensure that pods meet defined Pod Security Standards|Use `Baseline` or `Restricted` pod security standards to prevent exploiting writable hostPath mount.| -------------------------------------------------------------------------------- /docs/techniques/bash or cmd inside container.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Bash or cmd inside container 8 | 9 | !!! info inline end 10 | ID: MS-TA9007
11 | Tactic: [Execution](../tactics/Execution/index.md)
12 | MITRE technique: [T1059](https://attack.mitre.org/techniques/T1059/) 13 | 14 | Attackers who have permissions to run a cmd/bash script inside a container can use it to execute malicious code and compromise cluster resources. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9011](../mitigations/MS-M9011%20Restrict%20Container%20Runtime%20using%20LSM.md)|Restrict Container Runtime using LSM|Restrict container runtime capabilities using LSM.| 21 | |[MS-M9012](../mitigations/MS-M9012%20Remove%20Tools%20from%20Container%20Images.md)|Remove Tools from Container Images|Remove bash and other terminals from container images.| -------------------------------------------------------------------------------- /docs/techniques/container service account.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Container service account 8 | 9 | !!! info inline end 10 | ID: MS-TA9016
11 | Tactic: [Credential Access](../tactics/CredentialAccess/index.md), [Lateral Movement](../tactics/LateralMovement/index.md), [Persistence](../tactics/Persistence/index.md)
12 | MITRE technique: [T1528](https://attack.mitre.org/techniques/T1528/) 13 | 14 | Service account (SA) represents an application identity in Kubernetes. By default, a Service Account access token is mounted to every created pod in the cluster and containers in the pod can send requests to the Kubernetes API server using the Service Account credentials. Attackers who get access to a pod can access the Service Account token (located in `/var/run/secrets/kubernetes.io/serviceaccount/token`) and perform actions in the cluster, according to the Service Account permissions. If RBAC is not enabled, the Service Account has unlimited permissions in the cluster. If RBAC is enabled, its permissions are determined by the RoleBindings \ ClusterRoleBindings that are associated with it. 15 | 16 | An attacker which get access to the Service Account token can also authenticate and access the Kubernetes API server from outside the cluster and maintain access to the cluster. 17 | 18 | ## Mitigations 19 | 20 | |ID|Mitigation|Description| 21 | |--|----------|-----------| 22 | |[MS-M9025](../mitigations/MS-M9025%20Disable%20Service%20Account%20Auto%20Mount.md)|Disable Service Account Auto Mount|Disable service account auto mount.| 23 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|Configure the Kubernetes RBAC such that each service account will have the minimal necessary permissions for the application’s functionality.| -------------------------------------------------------------------------------- /docs/techniques/images from a private registry.md: -------------------------------------------------------------------------------- 1 | --- 2 | hide: 3 | - toc 4 | - footer 5 | --- 6 | 7 | # Images from a private registry 8 | 9 | !!! info inline end 10 | ID: MS-TA9037
11 | Tactic: [Collection](../tactics/Collection/index.md)
12 | MITRE technique: [T1530](https://attack.mitre.org/techniques/T1530/) 13 | 14 | The images that are running in the cluster can be stored in a private registry. For pulling those images, the container runtime engine (such as Docker or containerd) needs to have valid credentials to those registries. If the registry is hosted by the cloud provider, in services like Azure Container Registry (ACR) or Amazon Elastic Container Registry (ECR), cloud credentials are used to authenticate to the registry. If attackers get access to the cluster, in some cases they can obtain access to the private registry and pull its images. For example, attackers can use the managed identity token as described in the “Access managed identity credential” technique. Similarly, in EKS, attackers can use the AmazonEC2ContainerRegistryReadOnly policy that is bound by default to the node’s IAM role. 15 | 16 | ## Mitigations 17 | 18 | |ID|Mitigation|Description| 19 | |--|----------|-----------| 20 | |[MS-M9018](../mitigations/MS-M9018%20Restricting%20cloud%20metadata%20API%20access.md)|Restricting cloud metadata API access|Restrict access to IMDS to prevent authentication with a private registry using cloud identities.| 21 | |[MS-M9003](../mitigations/MS-M9003%20Adhere%20to%20least-privilege%20principle.md)|Adhere to least-privilege principle|In some configurations, the credentials to private registries are stored as Kubernetes secret. Adhere to least-privilege principle to prevent users from reading image pull secrets.| -------------------------------------------------------------------------------- /mkdocs.yml: -------------------------------------------------------------------------------- 1 | site_name: Threat Matrix for Kubernetes 2 | theme: 3 | name: material 4 | palette: 5 | - scheme: default 6 | primary: blue 7 | logo: assets/Microsoft.png 8 | favicon: assets/mdc.png 9 | language: en 10 | features: 11 | - navigation.tabs 12 | - navigation.tabs.sticky 13 | - navigation.indexes 14 | - navigation.top 15 | markdown_extensions: 16 | - tables 17 | - admonition 18 | - pymdownx.details 19 | - pymdownx.superfences 20 | - def_list 21 | extra_css: 22 | - stylesheets/extra.css 23 | nav: 24 | - Tactics: 25 | - 'index.md' 26 | - Initial Access: 27 | - 'tactics/InitialAccess/index.md' 28 | - Using cloud credentials: 'techniques/Using Cloud Credentials.md' 29 | - Compromised image In registry: 'techniques/Compromised Image In Registry.md' 30 | - Kubeconfig file: 'techniques/Kubeconfig file.md' 31 | - Application vulnerability: 'techniques/Application Vulnerability.md' 32 | - Exposed sensitive interfaces: 'techniques/Exposed sensitive interfaces.md' 33 | - Execution: 34 | - 'tactics/Execution/index.md' 35 | - Exec into container: 'techniques/Exec into container.md' 36 | - Bash/cmd inside container: 'techniques/bash or cmd inside container.md' 37 | - New container: 'techniques/New Container.md' 38 | - Application exploit (RCE): 'techniques/Application Exploit (RCE).md' 39 | - SSH server running inside container: 'techniques/SSH server running inside container.md' 40 | - Sidecar injection: 'techniques/Sidecar Injection.md' 41 | - Persistence: 42 | - 'tactics/Persistence/index.md' 43 | - Backdoor Container: 'techniques/Backdoor container.md' 44 | - Writable hostPath mount: 'techniques/Writable hostPath mount.md' 45 | - Kubernetes CronJob: 'techniques/Kubernetes CronJob.md' 46 | - Malicious admission controller: 'techniques/Malicious admission controller.md' 47 | - Container service account: 'techniques/container service account.md' 48 | - Static pods: 'techniques/Static Pods.md' 49 | - Privilege Escalation: 50 | - 'tactics/PrivilegeEscalation/index.md' 51 | - Privileged container: 'techniques/Privileged container.md' 52 | - Cluster-admin Binding: 'techniques/Cluster-admin binding.md' 53 | - Writable hostPath mount: 'techniques/Writable hostPath mount.md' 54 | - Access cloud resources: 'techniques/Access cloud resources.md' 55 | - Defense Evasion: 56 | - 'tactics/DefenseEvasion/index.md' 57 | - Clear container logs: 'techniques/Clear container logs.md' 58 | - Delete Kubernetes events: 'techniques/Delete K8S events.md' 59 | - Pod or container name similarity: 'techniques/Pod or container name similarily.md' 60 | - Connect from proxy server: 'techniques/Connect from Proxy server.md' 61 | - Credential Access: 62 | - 'tactics/CredentialAccess/index.md' 63 | - List Kubernetes secrets: 'techniques/List K8S secrets.md' 64 | - Mount service principal: 'techniques/Mount service principal.md' 65 | - Container service account: 'techniques/container service account.md' 66 | - Application credentials in configuration files: 'techniques/Application credentials in configuration files.md' 67 | - Access Managed Identity credentials: 'techniques/Access managed identity credentials.md' 68 | - Malicious admission controller: 'techniques/Malicious admission controller.md' 69 | - Discovery: 70 | - 'tactics/Discovery/index.md' 71 | - Access Kubernetes API server: 'techniques/Access the K8S API server.md' 72 | - Access Kubelet API: 'techniques/Access Kubelet API.md' 73 | - Network mapping: 'techniques/Network mapping.md' 74 | - Exposed sensitive interfaces: 'techniques/Exposed sensitive interfaces.md' 75 | - Instance Metadata API: 'techniques/Instance Metadata API.md' 76 | - Lateral Movement: 77 | - 'tactics/LateralMovement/index.md' 78 | - Access cloud resources: 'techniques/Access cloud resources.md' 79 | - Container service account: 'techniques/container service account.md' 80 | - Cluster internal networking: 'techniques/Cluster internal networking.md' 81 | - Application credentials in configuration files: 'techniques/Application credentials in configuration files.md' 82 | - Writable hostPath mount: 'techniques/Writable hostPath mount.md' 83 | - CoreDNS poisoning: 'techniques/CoreDNS poisoning.md' 84 | - ARP poisoning and IP spoofing: 'techniques/ARP poisoning and IP spoofing.md' 85 | - Collection: 86 | - 'tactics/Collection/index.md' 87 | - Images from a private registry: 'techniques/images from a private registry.md' 88 | - Collecting data from pod: 'techniques/Collecting Data from Pod.md' 89 | - Impact: 90 | - 'tactics/Impact/index.md' 91 | - Data destruction: 'techniques/Data destruction.md' 92 | - Resource hijacking: 'techniques/Resource hijacking.md' 93 | - Denial of service: 'techniques/Denial of service.md' 94 | - Mitigations: 95 | - 'mitigations/index.md' 96 | - Multi-factor authentication: 'mitigations/MS-M9001 Multi-factor Authentication.md' 97 | - Restrict access to the API server using IP firewall: 'mitigations/MS-M9002 Restrict access to the API server using IP firewall.md' 98 | - Adhere to least-privilege principle: 'mitigations/MS-M9003 Adhere to least-privilege principle.md' 99 | - Secure CI/CD environment: 'mitigations/MS-M9004 Secure CI CD environment.md' 100 | - Image assurance policy: 101 | - 'mitigations/MS-M9005/index.md' 102 | - Gate generated images in CI/CD pipeline: 'mitigations/MS-M9005/MS-M9005.001 Gate generated images in CI CD pipeline.md' 103 | - Gate images pushed to registries: 'mitigations/MS-M9005/MS-M9005.002 Gate images pushed to registries.md' 104 | - Gate images deployed to Kubernetes cluster: 'mitigations/MS-M9005/MS-M9005.003 Gate images deployed to Kubenertes cluster.md' 105 | - Enable Just In Time access to API server: 'mitigations/MS-M9006 Enable Just In Time access to API server.md' 106 | - Network intrusion prevention: 'mitigations/MS-M9007 Network Intrusion Prevention.md' 107 | - Limit access to services over network: 'mitigations/MS-M9008 Limit Access to Services Over Network.md' 108 | - Require strong authentication to services: 'mitigations/MS-M9009 Require Strong Authentication to Services.md' 109 | - Restrict exec commands on pods: 'mitigations/MS-M9010 Restrict Exec Commands on Pods.md' 110 | - Restrict container runtime using LSM: 'mitigations/MS-M9011 Restrict Container Runtime using LSM.md' 111 | - Remove tools from container images: 'mitigations/MS-M9012 Remove Tools from Container Images.md' 112 | - Restrict over permissive containers: 'mitigations/MS-M9013 Restrict over permissive containers.md' 113 | - Network segmentation: 'mitigations/MS-M9014 Network Segmentation.md' 114 | - Avoid running management interface on containers: 'mitigations/MS-M9015 Avoid Running Management Interface on Containers.md' 115 | - Restrict file and directory permissions: 'mitigations/MS-M9016 Restrict File and Directory Permissions.md' 116 | - Ensure that pods meet defined Pod Security Standards: 'mitigations/MS-M9017 Ensure that pods meet defined Pod Security Standards.md' 117 | - Restricting cloud metadata API access: 'mitigations/MS-M9018 Restricting cloud metadata API access.md' 118 | - Allocate specific identities to pods: 'mitigations/MS-M9019 Allocate specific identities to pods.md' 119 | - Collect logs to remote data storage: 'mitigations/MS-M9020 Collect Logs to Remote Data Storage.md' 120 | - Restrict the usage of unauthenticated APIs in the cluster: 'mitigations/MS-M9021 Restrict the usage of unauthenticated APIs in the Cluster.md' 121 | - Use managed secret store: 'mitigations/MS-M9022 Use Managed Secret Store.md' 122 | - Remove unused secrets from the cluster: 'mitigations/MS-M9023 Remove unused secrets from the cluster.md' 123 | - Restrict access to etcd: 'mitigations/MS-M9024 Restrict access to etcd.md' 124 | - Disable service account auto mount: 'mitigations/MS-M9025 Disable Service Account Auto Mount.md' 125 | - Avoid using plain text credentials: 'mitigations/MS-M9026 Avoid using plain text credentials in configuration files.md' 126 | - Use NodeRestriction admission controller: 'mitigations/MS-M9027 Use NodeRestriction Admission Controller.md' 127 | - Use CNIs that are not prone to ARP poisoning: 'mitigations/MS-M9028 Use CNIs that are not prone to ARP poisoning.md' 128 | - Set requests and limits for containers: 'mitigations/MS-M9029 Set requests and limits for containers.md' 129 | - Use cloud storage provider: 'mitigations/MS-M9030 Use Cloud Storage Provider.md' 130 | - Implement data backup strategy: 'mitigations/MS-M9031 Implement Data Backup Strategy.md' 131 | - Avoid using web-hosted manifest for Kubelet: 'mitigations/MS-M9032 Avoid using web-hosted manifest for Kubelet.md' 132 | - About: 'about.md' -------------------------------------------------------------------------------- /serve_docs.bat: -------------------------------------------------------------------------------- 1 | @echo off 2 | 3 | setlocal EnableDelayedExpansion 4 | 5 | :: setup a local development environment by creating a virtual environment 6 | :: resoring packages and making sure modules under src path are discoverable to unit tests 7 | if not exist .env ( 8 | echo Creating virtual environment at .env 9 | python -m venv .env 10 | ) 11 | 12 | :: we use cmd /k so that the restore and other commands will run inside the scope of the venv terminal 13 | :: in addition && is used so that commands will run only if previous call succeeded (errorlevel neq 0) 14 | echo Activating virtual environment 15 | if "%1"=="" ( 16 | cmd /k ".env\Scripts\activate.bat && pip install mkdocs-material==8.5.3 && mkdocs build && mkdocs serve" 17 | ) else ( 18 | echo bad arg "%1" && exit /b 1 19 | ) 20 | echo Setup complete 21 | 22 | set EX=!errorlevel! 23 | if "%EX%" neq "0" ( 24 | echo Failed to initialize 25 | popd 26 | exit /b %EX% 27 | ) 28 | 29 | exit /b 0 --------------------------------------------------------------------------------