last sync: 2023-Jan-27 18:40:07 UTC

Azure Policy definition

Role-Based Access Control (RBAC) should be used on Kubernetes Services

Name Role-Based Access Control (RBAC) should be used on Kubernetes Services
Azure Portal
Id ac4a19c2-fa67-49b4-8ae5-0b2e78c49457
Version 1.0.2
details on versioning
Category Security Center
Microsoft docs
Description To provide granular filtering on the actions that users can perform, use Role-Based Access Control (RBAC) to manage permissions in Kubernetes Service Clusters and configure relevant authorization policies.
Mode All
Type BuiltIn
Preview FALSE
Deprecated FALSE
Effect Default
Audit
Allowed
Audit, Disabled
RBAC
Role(s)
none
Rule
Aliases
IF (1)
Alias Namespace ResourceType DefaultPath Modifiable
Microsoft.ContainerService/managedClusters/enableRBAC Microsoft.ContainerService managedClusters properties.enableRBAC false
Rule
ResourceTypes
IF (1)
Microsoft.ContainerService/managedClusters
Compliance The following 30 compliance controls are associated with this Policy definition 'Role-Based Access Control (RBAC) should be used on Kubernetes Services' (ac4a19c2-fa67-49b4-8ae5-0b2e78c49457)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
Azure_Security_Benchmark_v1.0 4.6 Azure_Security_Benchmark_v1.0_4.6 Azure Security Benchmark 4.6 Data Protection Use Azure RBAC to control access to resources Customer Use Azure AD RBAC to control access to data and resources, otherwise use service specific access control methods. How to configure RBAC in Azure: https://docs.microsoft.com/azure/role-based-access-control/role-assignments-portal n/a link 2
Azure_Security_Benchmark_v2.0 PA-7 Azure_Security_Benchmark_v2.0_PA-7 Azure Security Benchmark PA-7 Privileged Access Follow just enough administration (least privilege principle) Customer Azure role-based access control (Azure RBAC) allows you to manage Azure resource access through role assignments. You can assign these roles to users, group service principals, and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell, and the Azure portal. The privileges you assign to resources through Azure RBAC should always be limited to what's required by the roles. Limited privileges complement the just in time (JIT) approach of Azure AD Privileged Identity Management (PIM), and those privileges should be reviewed periodically. Use built-in roles to allocate permission and only create custom role when required. What is Azure role-based access control (Azure RBAC): https://docs.microsoft.com/azure/role-based-access-control/overview How to configure Azure RBAC: https://docs.microsoft.com/azure/role-based-access-control/role-assignments-portal How to use Azure AD identity and access reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview n/a link 3
Azure_Security_Benchmark_v3.0 PA-7 Azure_Security_Benchmark_v3.0_PA-7 Azure Security Benchmark PA-7 Privileged Access Follow just enough administration (least privilege) principle Shared **Security Principle:** Follow the just enough administration (least privilege) principle to manage permissions at fine-grained level. Use features such as role-based access control (RBAC) to manage resource access through role assignments. **Azure Guidance:** Use Azure role-based access control (Azure RBAC) to manage Azure resource access through role assignments. Through RBAC, you can assign roles to users, group service principals, and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell, and the Azure portal. The privileges you assign to resources through Azure RBAC should always be limited to what's required by the roles. Limited privileges will complement the just-in-time (JIT) approach of Azure AD Privileged Identity Management (PIM), and those privileges should be reviewed periodically. If required, you can also use PIM to define the time-length (time-bound-assignment) condition in role assignment where a user can activate or use the role only within start and end dates. Note: Use Azure built-in roles to allocate permissions and only create custom roles when required. **Implementation and additional context:** What is Azure role-based access control (Azure RBAC): https://docs.microsoft.com/azure/role-based-access-control/overview How to configure RBAC in Azure: https://docs.microsoft.com/azure/role-based-access-control/role-assignments-portal How to use Azure AD identity and access reviews: https://docs.microsoft.com/azure/active-directory/governance/access-reviews-overview Azure AD Privileged Identity Management - Time-bound assignment: https://docs.microsoft.com/azure/active-directory/privileged-identity-management/pim-configure#what-does-it-do n/a link 2
CIS_Azure_1.1.0 8.5 CIS_Azure_1.1.0_8.5 CIS Microsoft Azure Foundations Benchmark recommendation 8.5 8 Other Security Considerations Enable role-based access control (RBAC) within Azure Kubernetes Services Shared The customer is responsible for implementing this recommendation. Ensure that RBAC is enabled on all Azure Kubernetes Services Instances link 7
CIS_Azure_1.3.0 8.5 CIS_Azure_1.3.0_8.5 CIS Microsoft Azure Foundations Benchmark recommendation 8.5 8 Other Security Considerations Enable role-based access control (RBAC) within Azure Kubernetes Services Shared The customer is responsible for implementing this recommendation. Ensure that RBAC is enabled on all Azure Kubernetes Services Instances link 7
CIS_Azure_1.4.0 8.7 CIS_Azure_1.4.0_8.7 CIS Microsoft Azure Foundations Benchmark recommendation 8.7 8 Other Security Considerations Enable role-based access control (RBAC) within Azure Kubernetes Services Shared The customer is responsible for implementing this recommendation. Ensure that RBAC is enabled on all Azure Kubernetes Services Instances link 7
CMMC_2.0_L2 AC.L1-3.1.1 CMMC_2.0_L2_AC.L1-3.1.1 404 not found n/a n/a 57
CMMC_2.0_L2 AC.L1-3.1.2 CMMC_2.0_L2_AC.L1-3.1.2 404 not found n/a n/a 19
CMMC_2.0_L2 AC.L2-3.1.5 CMMC_2.0_L2_AC.L2-3.1.5 404 not found n/a n/a 3
CMMC_L3 AC.1.001 CMMC_L3_AC.1.001 CMMC L3 AC.1.001 Access Control Limit information system access to authorized users, processes acting on behalf of authorized users, and devices (including other information systems). Shared Microsoft and the customer share responsibilities for implementing this requirement. Access control policies (e.g., identity- or role-based policies, control matrices, and cryptography) control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, and domains) in systems. Access enforcement mechanisms can be employed at the application and service level to provide increased information security. Other systems include systems internal and external to the organization. This requirement focuses on account management for systems and applications. The definition of and enforcement of access authorizations, other than those determined by account type (e.g., privileged verses non-privileged) are addressed in requirement AC.1.002. link 32
CMMC_L3 AC.1.002 CMMC_L3_AC.1.002 CMMC L3 AC.1.002 Access Control Limit information system access to the types of transactions and functions that authorized users are permitted to execute. Shared Microsoft and the customer share responsibilities for implementing this requirement. Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-oforigin. In defining other account attributes, organizations consider system-related requirements (e.g., system upgrades scheduled maintenance,) and mission or business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements). link 28
CMMC_L3 AC.2.007 CMMC_L3_AC.2.007 CMMC L3 AC.2.007 Access Control Employ the principle of least privilege, including for specific security functions and privileged accounts. Shared Microsoft and the customer share responsibilities for implementing this requirement. Organizations employ the principle of least privilege for specific duties and authorized accesses for users and processes. The principle of least privilege is applied with the goal of authorized privileges no higher than necessary to accomplish required organizational missions or business functions. Organizations consider the creation of additional processes, roles, and system accounts as necessary, to achieve least privilege. Organizations also apply least privilege to the development, implementation, and operation of organizational systems. Security functions include establishing system accounts, setting events to be logged, setting intrusion detection parameters, and configuring access authorizations (i.e., permissions, privileges). Privileged accounts, including super user accounts, are typically described as system administrator for various types of commercial off-the-shelf operating systems. Restricting privileged accounts to specific personnel or roles prevents day-to-day users from having access to privileged information or functions. Organizations may differentiate in the application of this requirement between allowed privileges for local accounts and for domain accounts provided organizations retain the ability to control system configurations for key security parameters and as otherwise necessary to sufficiently mitigate risk. link 4
CMMC_L3 AC.2.016 CMMC_L3_AC.2.016 CMMC L3 AC.2.016 Access Control Control the flow of CUI in accordance with approved authorizations. Shared Microsoft and the customer share responsibilities for implementing this requirement. Information flow control regulates where information can travel within a system and between systems (versus who can access the information) and without explicit regard to subsequent accesses to that information. Flow control restrictions include the following: keeping exportcontrolled information from being transmitted in the clear to the Internet; blocking outside traffic that claims to be from within the organization; restricting requests to the Internet that are not from the internal web proxy server; and limiting information transfers between organizations based on data structures and content. Organizations commonly use information flow control policies and enforcement mechanisms to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within systems and between interconnected systems. Flow control is based on characteristics of the information or the information path. Enforcement occurs in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict system services, provide a packetfiltering capability based on header information, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Organizations also consider the trustworthiness of filtering and inspection mechanisms (i.e., hardware, firmware, and software components) that are critical to information flow enforcement. Transferring information between systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies. In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems. Organizations consider mandating specific architectural solutions when required to enforce specific security policies. Enforcement includes: prohibiting information transfers between interconnected systems (i.e., allowing access only); employing hardware mechanisms to enforce one-way information flows; and implementing trustworthy regrading mechanisms to reassign security attributes and security labels. link 18
CMMC_L3 CM.2.062 CMMC_L3_CM.2.062 CMMC L3 CM.2.062 Configuration Management Employ the principle of least functionality by configuring organizational systems to provide only essential capabilities. Shared Microsoft and the customer share responsibilities for implementing this requirement. Systems can provide a wide variety of functions and services. Some of the functions and services routinely provided by default, may not be necessary to support essential organizational missions, functions, or operations. It is sometimes convenient to provide multiple services from single system components. However, doing so increases risk over limiting the services provided by any one component. Where feasible, organizations limit component functionality to a single function per component. Organizations review functions and services provided by systems or components of systems, to determine which functions and services are candidates for elimination. Organizations disable unused or unnecessary physical and logical ports and protocols to prevent unauthorized connection of devices, transfer of information, and tunneling. Organizations can utilize network scanning tools, intrusion detection and prevention systems, and end-point protections such as firewalls and host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports, protocols, and services. link 2
hipaa 1149.01c2System.9-01.c hipaa-1149.01c2System.9-01.c 1149.01c2System.9 - 01.c Privilege Management 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. Customer n/a Sample of signed information sharing agreements (e.g., disclosure agreements) with business partners, depicting sharing terms and conditions.

Third-party security policy and procedures (e.g., Azure Third Party Management SOP).
1
hipaa 1153.01c3System.35-01.c hipaa-1153.01c3System.35-01.c 1153.01c3System.35-01.c 11 Access Control 1153.01c3System.35-01.c 01.02 Authorized Access to Information Systems Shared n/a All file system access not explicitly required is disabled, and only authorized users are permitted access to only that which is expressly required for the performance of the users' job duties. 2
hipaa 1229.09c1Organizational.1-09.c hipaa-1229.09c1Organizational.1-09.c 1229.09c1Organizational.1-09.c 12 Audit Logging & Monitoring 1229.09c1Organizational.1-09.c 09.01 Documented Operating Procedures Shared n/a Separation of duties is used to limit the risk of unauthorized or unintentional modification of information and systems. 4
NIST_SP_800-53_R4 AC-3(7) NIST_SP_800-53_R4_AC-3(7) NIST SP 800-53 Rev. 4 AC-3 (7) Access Control Role-based Access Control Customer n/a The information system enforces a role-based access control policy over defined subjects and objects and controls access based upon [Assignment: organization-defined roles and users authorized to assume such roles]. link 1
NIST_SP_800-53_R5 AC-3(7) NIST_SP_800-53_R5_AC-3(7) NIST SP 800-53 Rev. 5 AC-3 (7) Access Control Role-based Access Control Customer n/a Enforce a role-based access control policy over defined subjects and objects and control access based upon [Assignment: organization-defined roles and users authorized to assume such roles]. link 1
NZ_ISM_v3.5 INF-9 NZ_ISM_v3.5_INF-9 NZISM Security Benchmark INF-9 Infrastructure 10.8.35 Security Architecture Customer n/a It is important that the principles of separation and segregation as well as the system classification are incorporated into the overall security architecture to maximise design and operational efficiency and to provide and support essential security to the network design. link 17
RBI_CSF_Banks_v2016 8.1 RBI_CSF_Banks_v2016_8.1 User Access Control / Management User Access Control / Management-8.1 n/a Provide secure access to the bank???s assets/services from within/outside bank???s network by protecting data/information at rest (e.g. using encryption, if supported by the device) and in-transit (e.g. using technologies such as VPN or other secure web protocols, etc.) 14
RBI_CSF_Banks_v2016 8.5 RBI_CSF_Banks_v2016_8.5 User Access Control / Management User Access Control / Management-8.5 n/a Implement appropriate (e.g. centralised) systems and controls to allow, manage, log and monitor privileged/superuser/administrative access to critical systems (Servers/OS/DB, applications, network devices etc.). 12
RBI_CSF_Banks_v2016 8.8 RBI_CSF_Banks_v2016_8.8 User Access Control / Management User Access Control / Management-8.8 n/a Implement measures to control installation of software on PCs/laptops, etc 2
RBI_ITF_NBFC_v2017 3.1.a RBI_ITF_NBFC_v2017_3.1.a RBI IT Framework 3.1.a Information and Cyber Security Identification and Classification of Information Assets-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Identification and Classification of Information Assets. NBFCs shall maintain detailed inventory of Information Asset with distinct and clear identification of the asset. link 7
RBI_ITF_NBFC_v2017 3.1.c RBI_ITF_NBFC_v2017_3.1.c RBI IT Framework 3.1.c Information and Cyber Security Role based Access Control-3.1 n/a The IS Policy must provide for a IS framework with the following basic tenets: Role based Access Control ??? Access to information should be based on well-defined user roles (system administrator, user manager, application owner etc.), NBFCs shall avoid dependence on one or few persons for a particular job. There should be clear delegation of authority for right to upgrade/change user profiles and permissions and also key business parameters (eg. interest rates) which should be documented. link 15
RMiT_v1.0 10.54 RMiT_v1.0_10.54 RMiT 10.54 Access Control Access Control - 10.54 Shared n/a A financial institution must implement an appropriate access controls policy for the identification, authentication and authorisation of users (internal and external users such as third party service providers). This must address both logical and physical technology access controls which are commensurate with the level of risk of unauthorised access to its technology systems. link 17
RMiT_v1.0 10.60 RMiT_v1.0_10.60 RMiT 10.60 Access Control Access Control - 10.60 Shared n/a A financial institution must establish a user access matrix to outline access rights, user roles or profiles, and the authorising and approving authorities. The access matrix must be periodically reviewed and updated. link 2
RMiT_v1.0 10.61 RMiT_v1.0_10.61 RMiT 10.61 Access Control Access Control - 10.61 Shared n/a A financial institution must ensure' (a) access controls to enterprise-wide systems are effectively managed and monitored; and (b) user activities in critical systems are logged for audit and investigations. Activity logs must be maintained for at least three years and regularly reviewed in a timely manner. link 8
RMiT_v1.0 10.62 RMiT_v1.0_10.62 RMiT 10.62 Access Control Access Control - 10.62 Shared n/a In fulfilling the requirement under paragraph 10.61, large financial institutions are required to' (a) deploy an identity access management system to effectively manage and monitor user access to enterprise-wide systems; and (b) deploy automated audit tools to flag any anomalies. link 2
SOC_2 CC6.3 SOC_2_CC6.3 SOC 2 Type 2 CC6.3 Logical and Physical Access Controls Rol based access and least privilege Shared The customer is responsible for implementing this recommendation. • Creates or Modifies Access to Protected Information Assets — Processes are in place to create or modify access to protected information assets based on authorization from the asset’s owner. • Removes Access to Protected Information Assets — Processes are in place to remove access to protected information assets when an individual no longer requires access. • Uses Role-Based Access Controls — Role-based access control is utilized to support segregation of incompatible functions. • Reviews Access Roles and Rules — The appropriateness of access roles and access rules is reviewed on a periodic basis for unnecessary and inappropriate individuals with access and access rules are modified as appropriate 20
History
Date/Time (UTC ymd) (i) Change type Change detail
2020-08-19 13:49:29 change Previous DisplayName: [Preview]: Role-Based Access Control (RBAC) should be used on Kubernetes Services
Initiatives
usage
Initiative DisplayName Initiative Id Initiative Category State Type
[Deprecated]: Azure Security Benchmark v1 42a694ed-f65e-42b2-aa9e-8052e9740a92 Regulatory Compliance Deprecated BuiltIn
[Deprecated]: Azure Security Benchmark v2 bb522ac1-bc39-4957-b194-429bcd3bcb0b Regulatory Compliance Deprecated BuiltIn
[Preview]: CMMC 2.0 Level 2 4e50fd13-098b-3206-61d6-d1d78205cb45 Regulatory Compliance Preview BuiltIn
[Preview]: Motion Picture Association of America (MPAA) 92646f03-e39d-47a9-9e24-58d60ef49af8 Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for Banks d0d5578d-cc08-2b22-31e3-f525374f235a Regulatory Compliance Preview BuiltIn
[Preview]: Reserve Bank of India - IT Framework for NBFC 7f89f09c-48c1-f28d-1bd5-84f3fb22f86c Regulatory Compliance Preview BuiltIn
Azure Security Benchmark 1f3afdf9-d0c9-4c3d-847f-89da613e70a8 Security Center GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.1.0 1a5bb27d-173f-493e-9568-eb56638dde4d Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.3.0 612b5213-9160-4969-8578-1518bd2a000c Regulatory Compliance GA BuiltIn
CIS Microsoft Azure Foundations Benchmark v1.4.0 c3f5c4d9-9a1d-4a99-85c0-7f93e384d5c5 Regulatory Compliance GA BuiltIn
CMMC Level 3 b5629c75-5c77-4422-87b9-2509e680f8de Regulatory Compliance GA BuiltIn
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
New Zealand ISM Restricted v3.5 93d2179e-3068-c82f-2428-d614ae836a04 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
RMIT Malaysia 97a6d4f1-3bed-4cf4-ac5b-0e444c0408d6 Regulatory Compliance GA BuiltIn
SOC 2 Type 2 4054785f-702b-4a98-9215-009cbd58b141 Regulatory Compliance GA BuiltIn
JSON