last sync: 2024-Jul-26 18:17:39 UTC

Kubernetes clusters should disable automounting API credentials

Azure BuiltIn Policy definition

Source Azure Portal
Display name Kubernetes clusters should disable automounting API credentials
Id 423dd1ba-798e-40e4-9c4d-b6902674b423
Version 4.1.0
Details on versioning
Category Kubernetes
Microsoft Learn
Description Disable automounting API credentials to prevent a potentially compromised Pod resource to run API commands against Kubernetes clusters. For more information, see https://aka.ms/kubepolicydoc.
Mode Microsoft.Kubernetes.Data
Type BuiltIn
Preview False
Deprecated False
Effect Default
Audit
Allowed
audit, Audit, deny, Deny, disabled, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types IF (2)
Microsoft.ContainerService/managedClusters
Microsoft.Kubernetes/connectedClusters
Compliance
The following 5 compliance controls are associated with this Policy definition 'Kubernetes clusters should disable automounting API credentials' (423dd1ba-798e-40e4-9c4d-b6902674b423)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v3.0 PV-2 Azure_Security_Benchmark_v3.0_PV-2 Microsoft cloud security benchmark PV-2 Posture and Vulnerability Management Audit and enforce secure configurations Shared **Security Principle:** Continuously monitor and alert when there is a deviation from the defined configuration baseline. Enforce the desired configuration according to the baseline configuration by denying the non-compliant configuration or deploy a configuration. **Azure Guidance:** Use Microsoft Defender for Cloud to configure Azure Policy to audit and enforce configurations of your Azure resources. Use Azure Monitor to create alerts when there is a configuration deviation detected on the resources. Use Azure Policy [deny] and [deploy if not exist] rule to enforce secure configuration across Azure resources. For resource configuration audit and enforcement not supported by Azure Policy, you may need to write your own scripts or use third-party tooling to implement the configuration audit and enforcement. **Implementation and additional context:** Understand Azure Policy effects: https://docs.microsoft.com/azure/governance/policy/concepts/effects Create and manage policies to enforce compliance: https://docs.microsoft.com/azure/governance/policy/tutorials/create-and-manage Get compliance data of Azure resources: https://docs.microsoft.com/azure/governance/policy/how-to/get-compliance-data n/a link 27
C.04.7 - Evaluated C.04.7 - Evaluated 404 not found n/a n/a 45
NZ_ISM_v3.5 SS-3 NZ_ISM_v3.5_SS-3 NZISM Security Benchmark SS-3 Software security 14.1.9 Maintaining hardened SOEs Customer n/a Whilst a SOE can be sufficiently hardened when it is deployed, its security will progressively degrade over time. Agencies can address the degradation of the security of a SOE by ensuring that patches are continually applied, system users are not able to disable or bypass security functionality and antivirus and other security software is appropriately maintained with the latest signatures and updates. End Point Agents monitor traffic and apply security policies on applications, storage interfaces and data in real-time. Administrators actively block or monitor and log policy breaches. The End Point Agent can also create forensic monitoring to facilitate incident investigation. End Point Agents can monitor user activity, such as the cut, copy, paste, print, print screen operations and copying data to external drives and other devices. The Agent can then apply policies to limit such activity. link 17
SOC_2 CC6.8 SOC_2_CC6.8 SOC 2 Type 2 CC6.8 Logical and Physical Access Controls Prevent or detect against unauthorized or malicious software Shared The customer is responsible for implementing this recommendation. Restricts Application and Software Installation — The ability to install applications and software is restricted to authorized individuals. • Detects Unauthorized Changes to Software and Configuration Parameters — Processes are in place to detect changes to software and configuration parameters that may be indicative of unauthorized or malicious software. • Uses a Defined Change Control Process — A management-defined change control process is used for the implementation of software. • Uses Antivirus and Anti-Malware Software — Antivirus and anti-malware software is implemented and maintained to provide for the interception or detection and remediation of malware. • Scans Information Assets from Outside the Entity for Malware and Other Unauthorized Software — Procedures are in place to scan information assets that have been transferred or returned to the entity’s custody for malware and other unauthorized software and to remove any items detected prior to its implementation on the network. 53
SOC_2 CC8.1 SOC_2_CC8.1 SOC 2 Type 2 CC8.1 Change Management Changes to infrastructure, data, and software Shared The customer is responsible for implementing this recommendation. Manages Changes Throughout the System Life Cycle — A process for managing system changes throughout the life cycle of the system and its components (infrastructure, data, software, and procedures) is used to support system availability and processing integrity. • Authorizes Changes — A process is in place to authorize system changes prior to development. • Designs and Develops Changes — A process is in place to design and develop system changes. • Documents Changes — A process is in place to document system changes to support ongoing maintenance of the system and to support system users in performing their responsibilities. • Tracks System Changes — A process is in place to track system changes prior to implementation. • Configures Software — A process is in place to select and implement the configuration parameters used to control the functionality of software. • Tests System Changes — A process is in place to test system changes prior to implementation. • Approves System Changes — A process is in place to approve system changes prior to implementation. • Deploys System Changes — A process is in place to implement system changes. • Identifies and Evaluates System Changes — Objectives affected by system changes are identified and the ability of the modified system to meet the objectives is evaluated throughout the system development life cycle. • Identifies Changes in Infrastructure, Data, Software, and Procedures Required to Remediate Incidents — Changes in infrastructure, data, software, and procedures required to remediate incidents to continue to meet objectives are identified and the change process is initiated upon identification. • Creates Baseline Configuration of IT Technology — A baseline configuration of IT and control systems is created and maintained. • Provides for Changes Necessary in Emergency Situations — A process is in place for authorizing, designing, testing, approving, and implementing changes necessary in emergency situations (that is, changes that need to be implemented in an urgent time frame). Additional points of focus that apply only in an engagement using the trust services criteria for confidentiality: • Protects Confidential Information — The entity protects confidential information during system design, development, testing, implementation, and change processes to meet the entity’s objectives related to confidentiality. Additional points of focus that apply only in an engagement using the trust services criteria for privacy: • Protects Personal Information — The entity protects personal information during system design, development, testing, implementation, and change processes to meet the entity’s objectives related to privacy. 52
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
[Deprecated]: New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance Deprecated BuiltIn
Microsoft cloud security benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
NL BIO Cloud Theme 6ce73208-883e-490f-a2ac-44aac3b3687f Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2023-05-01 17:41:52 change Minor (4.0.1 > 4.1.0)
2022-10-21 16:42:13 change Patch (4.0.0 > 4.0.1)
2022-09-19 17:41:40 change Major (3.0.1 > 4.0.0)
2022-06-17 16:31:08 change Patch (3.0.0 > 3.0.1)
2022-06-10 16:31:21 change Major (2.1.0 > 3.0.0)
2022-04-01 20:29:14 change Minor (2.0.2 > 2.1.0)
2021-12-06 22:17:57 change Patch (2.0.1 > 2.0.2)
2021-10-04 15:27:15 change Version remains equal, old suffix: preview (2.0.1-preview > 2.0.1)
2021-09-08 15:39:57 change Patch, suffix remains equal (2.0.0-preview > 2.0.1-preview)
2021-03-02 15:11:40 change Major, suffix remains equal (1.0.0-preview > 2.0.0-preview)
2020-12-11 15:42:52 add 423dd1ba-798e-40e4-9c4d-b6902674b423
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC