Azure Policy Regulatory Compliance controls for Azure Kubernetes Service (AKS)
Regulatory Compliance in Azure Policy provides initiative definitions (built-ins) created and managed by Microsoft, for the compliance domains and security controls related to different compliance standards. This page lists the Azure Kubernetes Service (AKS) compliance domains and security controls.
You can assign the built-ins for a security control individually to help make your Azure resources compliant with the specific standard.
The title of each built-in policy definition links to the policy definition in the Azure portal. Use the link in the Policy Version column to view the source on the Azure Policy GitHub repo.
Important
Each control is associated with one or more Azure Policy definitions. These policies might help you assess compliance with the control. However, there often isn't a one-to-one or complete match between a control and one or more policies. As such, Compliant in Azure Policy refers only to the policies themselves. This doesn't ensure that you're fully compliant with all requirements of a control. In addition, the compliance standard includes controls that aren't addressed by any Azure Policy definitions at this time. Therefore, compliance in Azure Policy is only a partial view of your overall compliance status. The associations between controls and Azure Policy Regulatory Compliance definitions for these compliance standards can change over time.
CIS Microsoft Azure Foundations Benchmark 1.1.0
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - CIS Microsoft Azure Foundations Benchmark 1.1.0. For more information about this compliance standard, see CIS Microsoft Azure Foundations Benchmark.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| 8 Other Security Considerations | 8.5 | Enable role-based access control (RBAC) within Azure Kubernetes Services | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
CIS Microsoft Azure Foundations Benchmark 1.3.0
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - CIS Microsoft Azure Foundations Benchmark 1.3.0. For more information about this compliance standard, see CIS Microsoft Azure Foundations Benchmark.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| 8 Other Security Considerations | 8.5 | Enable role-based access control (RBAC) within Azure Kubernetes Services | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
CIS Microsoft Azure Foundations Benchmark 1.4.0
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance details for CIS v1.4.0. For more information about this compliance standard, see CIS Microsoft Azure Foundations Benchmark.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| 8 Other Security Considerations | 8.7 | Enable role-based access control (RBAC) within Azure Kubernetes Services | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
CMMC Level 3
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - CMMC Level 3. For more information about this compliance standard, see Cybersecurity Maturity Model Certification (CMMC).
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| Access Control | AC.1.001 | Limit information system access to authorized users, processes acting on behalf of authorized users, and devices (including other information systems). | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| Access Control | AC.1.001 | Limit information system access to authorized users, processes acting on behalf of authorized users, and devices (including other information systems). | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| Access Control | AC.1.002 | Limit information system access to the types of transactions and functions that authorized users are permitted to execute. | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| Access Control | AC.1.002 | Limit information system access to the types of transactions and functions that authorized users are permitted to execute. | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| Access Control | AC.2.007 | Employ the principle of least privilege, including for specific security functions and privileged accounts. | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| Access Control | AC.2.016 | Control the flow of CUI in accordance with approved authorizations. | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| Configuration Management | CM.2.062 | Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| Configuration Management | CM.3.068 | Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| Risk Assessment | RM.2.143 | Remediate vulnerabilities in accordance with risk assessments. | Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version | 1.0.2 |
| System and Communications Protection | SC.1.175 | Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems. | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| System and Communications Protection | SC.3.177 | Employ FIPS-validated cryptography when used to protect the confidentiality of CUI. | Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys | 1.0.1 |
| System and Communications Protection | SC.3.183 | Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception). | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| System and Information Integrity | SI.1.210 | Identify, report, and correct information and information system flaws in a timely manner. | Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version | 1.0.2 |
FedRAMP High
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - FedRAMP High. For more information about this compliance standard, see FedRAMP High.
FedRAMP Moderate
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - FedRAMP Moderate. For more information about this compliance standard, see FedRAMP Moderate.
HIPAA HITRUST 9.2
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - HIPAA HITRUST 9.2. For more information about this compliance standard, see HIPAA HITRUST 9.2.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| Privilege Management | 1149.01c2System.9 - 01.c | The organization facilitates information sharing by enabling authorized users to determine a business partner's access when discretion is allowed as defined by the organization and by employing manual processes or automated mechanisms to assist users in making information sharing/collaboration decisions. | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| 11 Access Control | 1153.01c3System.35-01.c | 1153.01c3System.35-01.c 01.02 Authorized Access to Information Systems | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| 12 Audit Logging & Monitoring | 1229.09c1Organizational.1-09.c | 1229.09c1Organizational.1-09.c 09.01 Documented Operating Procedures | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
Microsoft Cloud for Sovereignty Baseline Confidential Policies
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance details for MCfS Sovereignty Baseline Confidential Policies. For more information about this compliance standard, see Microsoft Cloud for Sovereignty Policy portfolio.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| SO.3 - Customer-Managed Keys | SO.3 | Azure products must be configured to use Customer-Managed Keys when possible. | Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys | 1.0.1 |
Microsoft cloud security benchmark
The Microsoft cloud security benchmark provides recommendations on how you can secure your cloud solutions on Azure. To see how this service completely maps to the Microsoft cloud security benchmark, see the Azure Security Benchmark mapping files.
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - Microsoft cloud security benchmark.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| Network Security | NS-2 | Secure cloud services with network controls | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 |
| Privileged Access | PA-7 | Follow just enough administration (least privilege) principle | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| Data Protection | DP-3 | Encrypt sensitive data in transit | Kubernetes clusters should be accessible only over HTTPS | 8.2.0 |
| Logging and Threat Detection | LT-1 | Enable threat detection capabilities | Azure Kubernetes Service clusters should have Defender profile enabled | 2.0.1 |
| Logging and Threat Detection | LT-2 | Enable threat detection for identity and access management | Azure Kubernetes Service clusters should have Defender profile enabled | 2.0.1 |
| Logging and Threat Detection | LT-3 | Enable logging for security investigation | Resource logs in Azure Kubernetes Service should be enabled | 1.0.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters | 1.0.2 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits | 9.3.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster containers should not share host process ID or host IPC namespace | 5.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster containers should only use allowed AppArmor profiles | 6.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster containers should only use allowed capabilities | 6.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster containers should only use allowed images | 9.3.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster containers should run with a read only root file system | 6.3.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster pod hostPath volumes should only use allowed host paths | 6.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster pods and containers should only run with approved user and group IDs | 6.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster services should listen only on allowed ports | 8.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes cluster should not allow privileged containers | 9.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes clusters should disable automounting API credentials | 4.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes clusters should not allow container privilege escalation | 7.2.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes clusters should not grant CAP_SYS_ADMIN security capabilities | 5.1.0 |
| Posture and Vulnerability Management | PV-2 | Audit and enforce secure configurations | Kubernetes clusters should not use the default namespace | 4.2.0 |
| Posture and Vulnerability Management | PV-6 | Rapidly and automatically remediate vulnerabilities | Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management) | 1.0.1 |
| DevOps Security | DS-6 | Enforce security of workload throughout DevOps lifecycle | Azure running container images should have vulnerabilities resolved (powered by Microsoft Defender Vulnerability Management) | 1.0.1 |
NIST SP 800-171 R2
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - NIST SP 800-171 R2. For more information about this compliance standard, see NIST SP 800-171 R2.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| Access Control | 3.1.3 | Control the flow of CUI in accordance with approved authorizations. | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 |
| System and Communications Protection | 3.13.1 | Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems. | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 |
| System and Communications Protection | 3.13.10 | Establish and manage cryptographic keys for cryptography employed in organizational systems. | Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys | 1.0.1 |
| System and Communications Protection | 3.13.16 | Protect the confidentiality of CUI at rest. | Temp disks and cache for agent node pools in Azure Kubernetes Service clusters should be encrypted at host | 1.0.1 |
| System and Communications Protection | 3.13.2 | Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems. | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 |
| System and Communications Protection | 3.13.5 | Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks. | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 |
| System and Communications Protection | 3.13.6 | Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception). | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 |
| System and Communications Protection | 3.13.8 | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards. | Kubernetes clusters should be accessible only over HTTPS | 8.2.0 |
| System and Information Integrity | 3.14.1 | Identify, report, and correct system flaws in a timely manner. | Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version | 1.0.2 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters | 1.0.2 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits | 9.3.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster containers should not share host process ID or host IPC namespace | 5.2.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster containers should only use allowed AppArmor profiles | 6.2.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster containers should only use allowed capabilities | 6.2.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster containers should only use allowed images | 9.3.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster containers should run with a read only root file system | 6.3.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster pod hostPath volumes should only use allowed host paths | 6.2.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster pods and containers should only run with approved user and group IDs | 6.2.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster services should listen only on allowed ports | 8.2.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes cluster should not allow privileged containers | 9.2.0 |
| Configuration Management | 3.4.1 | Establish and maintain baseline configurations and inventories of organizational systems (including hardware, software, firmware, and documentation) throughout the respective system development life cycles. | Kubernetes clusters should not allow container privilege escalation | 7.2.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters | 1.0.2 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits | 9.3.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster containers should not share host process ID or host IPC namespace | 5.2.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster containers should only use allowed AppArmor profiles | 6.2.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster containers should only use allowed capabilities | 6.2.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster containers should only use allowed images | 9.3.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster containers should run with a read only root file system | 6.3.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster pod hostPath volumes should only use allowed host paths | 6.2.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster pods and containers should only run with approved user and group IDs | 6.2.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster services should listen only on allowed ports | 8.2.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes cluster should not allow privileged containers | 9.2.0 |
| Configuration Management | 3.4.2 | Establish and enforce security configuration settings for information technology products employed in organizational systems. | Kubernetes clusters should not allow container privilege escalation | 7.2.0 |
NIST SP 800-53 Rev. 4
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - NIST SP 800-53 Rev. 4. For more information about this compliance standard, see NIST SP 800-53 Rev. 4.
NIST SP 800-53 Rev. 5
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - NIST SP 800-53 Rev. 5. For more information about this compliance standard, see NIST SP 800-53 Rev. 5.
NL BIO Cloud Theme
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance details for NL BIO Cloud Theme. For more information about this compliance standard, see Baseline Information Security Government Cybersecurity - Digital Government (digitaleoverheid.nl).
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| C.04.3 Technical vulnerability management - Timelines | C.04.3 | If the probability of abuse and the expected damage are both high, patches are installed no later than within a week. | Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version | 1.0.2 |
| C.04.6 Technical vulnerability management - Timelines | C.04.6 | Technical weaknesses can be remedied by performing patch management in a timely manner. | Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version | 1.0.2 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters | 1.0.2 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits | 9.3.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster containers should not share host process ID or host IPC namespace | 5.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster containers should only use allowed AppArmor profiles | 6.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster containers should only use allowed capabilities | 6.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster containers should only use allowed images | 9.3.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster containers should run with a read only root file system | 6.3.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster pod hostPath volumes should only use allowed host paths | 6.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster pods and containers should only run with approved user and group IDs | 6.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster services should listen only on allowed ports | 8.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes cluster should not allow privileged containers | 9.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes clusters should disable automounting API credentials | 4.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes clusters should not allow container privilege escalation | 7.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes clusters should not grant CAP_SYS_ADMIN security capabilities | 5.1.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes clusters should not use the default namespace | 4.2.0 |
| C.04.7 Technical vulnerability management - Evaluated | C.04.7 | Evaluations of technical vulnerabilities are recorded and reported. | Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version | 1.0.2 |
| U.05.1 Data protection - Cryptographic measures | U.05.1 | Data transport is secured with cryptography where key management is carried out by the CSC itself if possible. | Kubernetes clusters should be accessible only over HTTPS | 8.2.0 |
| U.05.2 Data protection - Cryptographic measures | U.05.2 | Data stored in the cloud service shall be protected to the latest state of the art. | Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys | 1.0.1 |
| U.05.2 Data protection - Cryptographic measures | U.05.2 | Data stored in the cloud service shall be protected to the latest state of the art. | Temp disks and cache for agent node pools in Azure Kubernetes Service clusters should be encrypted at host | 1.0.1 |
| U.07.1 Data separation - Isolated | U.07.1 | Permanent isolation of data is a multi-tenant architecture. Patches are realized in a controlled manner. | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 |
| U.07.3 Data separation - Management features | U.07.3 | U.07.3 - The privileges to view or modify CSC data and/or encryption keys are granted in a controlled manner and use is logged. | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| U.09.3 Malware Protection - Detection, prevention and recovery | U.09.3 | The malware protection runs on different environments. | Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version | 1.0.2 |
| U.10.2 Access to IT services and data - Users | U.10.2 | Under the responsibility of the CSP, access is granted to administrators. | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| U.10.3 Access to IT services and data - Users | U.10.3 | Only users with authenticated equipment can access IT services and data. | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| U.10.5 Access to IT services and data - Competent | U.10.5 | Access to IT services and data is limited by technical measures and has been implemented. | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| U.11.1 Cryptoservices - Policy | U.11.1 | In the cryptography policy, at least the subjects in accordance with BIO have been elaborated. | Kubernetes clusters should be accessible only over HTTPS | 8.2.0 |
| U.11.2 Cryptoservices - Cryptographic measures | U.11.2 | In case of PKIoverheid certificates use PKIoverheid requirements for key management. In other situations use ISO11770. | Kubernetes clusters should be accessible only over HTTPS | 8.2.0 |
| U.11.3 Cryptoservices - Encrypted | U.11.3 | Sensitive data is always encrypted, with private keys managed by the CSC. | Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys | 1.0.1 |
| U.11.3 Cryptoservices - Encrypted | U.11.3 | Sensitive data is always encrypted, with private keys managed by the CSC. | Temp disks and cache for agent node pools in Azure Kubernetes Service clusters should be encrypted at host | 1.0.1 |
| U.15.1 Logging and monitoring - Events logged | U.15.1 | The violation of the policy rules is recorded by the CSP and the CSC. | Resource logs in Azure Kubernetes Service should be enabled | 1.0.0 |
Reserve Bank of India - IT Framework for NBFC
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - Reserve Bank of India - IT Framework for NBFC. For more information about this compliance standard, see Reserve Bank of India - IT Framework for NBFC.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| IT Governance | 1 | IT Governance-1 | Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version | 1.0.2 |
| Information and Cyber Security | 3.1.a | Identification and Classification of Information Assets-3.1 | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| Information and Cyber Security | 3.1.c | Role based Access Control-3.1 | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| Information and Cyber Security | 3.1.g | Trails-3.1 | Azure Kubernetes Service clusters should have Defender profile enabled | 2.0.1 |
| Information and Cyber Security | 3.3 | Vulnerability Management-3.3 | Kubernetes Services should be upgraded to a non-vulnerable Kubernetes version | 1.0.2 |
Reserve Bank of India IT Framework for Banks v2016
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - RBI ITF Banks v2016. For more information about this compliance standard, see RBI ITF Banks v2016 (PDF).
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| Patch/Vulnerability & Change Management | Patch/Vulnerability & Change Management-7.7 | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 | |
| Advanced Real-Timethreat Defenceand Management | Advanced Real-Timethreat Defenceand Management-13.2 | Azure Kubernetes Service clusters should have Defender profile enabled | 2.0.1 | |
| User Access Control / Management | User Access Control / Management-8.1 | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
RMIT Malaysia
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance - RMIT Malaysia. For more information about this compliance standard, see RMIT Malaysia.
Spain ENS
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance details for Spain ENS. For more information about this compliance standard, see CCN-STIC 884.
SWIFT CSP-CSCF v2021
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance details for SWIFT CSP-CSCF v2021. For more information about this compliance standard, see SWIFT CSP CSCF v2021.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| SWIFT Environment Protection | 1.1 | SWIFT Environment Protection | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 |
| SWIFT Environment Protection | 1.4 | Restriction of Internet Access | Authorized IP ranges should be defined on Kubernetes Services | 2.0.1 |
| Reduce Attack Surface and Vulnerabilities | 2.1 | Internal Data Flow Security | Kubernetes clusters should be accessible only over HTTPS | 8.2.0 |
| Detect Anomalous Activity to Systems or Transaction Records | 6.2 | Software Integrity | Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys | 1.0.1 |
| Detect Anomalous Activity to Systems or Transaction Records | 6.5A | Intrusion Detection | Both operating systems and data disks in Azure Kubernetes Service clusters should be encrypted by customer-managed keys | 1.0.1 |
System and Organization Controls (SOC) 2
To review how the available Azure Policy built-ins for all Azure services map to this compliance standard, see Azure Policy Regulatory Compliance details for System and Organization Controls (SOC) 2. For more information about this compliance standard, see System and Organization Controls (SOC) 2.
| Domain | Control ID | Control title | Policy (Azure portal) |
Policy version (GitHub) |
|---|---|---|---|---|
| Logical and Physical Access Controls | CC6.1 | Logical access security software, infrastructure, and architectures | Kubernetes clusters should be accessible only over HTTPS | 8.2.0 |
| Logical and Physical Access Controls | CC6.3 | Rol based access and least privilege | Role-Based Access Control (RBAC) should be used on Kubernetes Services | 1.0.4 |
| Logical and Physical Access Controls | CC6.6 | Security measures against threats outside system boundaries | Kubernetes clusters should be accessible only over HTTPS | 8.2.0 |
| Logical and Physical Access Controls | CC6.7 | Restrict the movement of information to authorized users | Kubernetes clusters should be accessible only over HTTPS | 8.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters | 1.0.2 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits | 9.3.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster containers should not share host process ID or host IPC namespace | 5.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster containers should only use allowed AppArmor profiles | 6.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster containers should only use allowed capabilities | 6.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster containers should only use allowed images | 9.3.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster containers should run with a read only root file system | 6.3.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster pod hostPath volumes should only use allowed host paths | 6.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster pods and containers should only run with approved user and group IDs | 6.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster services should listen only on allowed ports | 8.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes cluster should not allow privileged containers | 9.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes clusters should disable automounting API credentials | 4.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes clusters should not allow container privilege escalation | 7.2.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes clusters should not grant CAP_SYS_ADMIN security capabilities | 5.1.0 |
| Logical and Physical Access Controls | CC6.8 | Prevent or detect against unauthorized or malicious software | Kubernetes clusters should not use the default namespace | 4.2.0 |
| System Operations | CC7.2 | Monitor system components for anomalous behavior | Azure Kubernetes Service clusters should have Defender profile enabled | 2.0.1 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters | 1.0.2 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster containers CPU and memory resource limits should not exceed the specified limits | 9.3.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster containers should not share host process ID or host IPC namespace | 5.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster containers should only use allowed AppArmor profiles | 6.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster containers should only use allowed capabilities | 6.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster containers should only use allowed images | 9.3.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster containers should run with a read only root file system | 6.3.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster pod hostPath volumes should only use allowed host paths | 6.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster pods and containers should only run with approved user and group IDs | 6.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster pods should only use approved host network and port range | 6.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster services should listen only on allowed ports | 8.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes cluster should not allow privileged containers | 9.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes clusters should disable automounting API credentials | 4.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes clusters should not allow container privilege escalation | 7.2.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes clusters should not grant CAP_SYS_ADMIN security capabilities | 5.1.0 |
| Change Management | CC8.1 | Changes to infrastructure, data, and software | Kubernetes clusters should not use the default namespace | 4.2.0 |
Next steps
- Learn more about Azure Policy Regulatory Compliance.
- See the built-ins on the Azure Policy GitHub repo.
Співпраця з нами на GitHub
Джерело цього вмісту можна знайти на GitHub, де також можна створювати й переглядати запитання та запити на внесення змін. Докладні відомості наведено в нашому посібнику для співавторів.
Azure Kubernetes Service