policy assignment managed identity

Assignment scopes and excluded scopes

• CSV Assignment Parameters
• Policy Exemptions

Policy Assignments

This chapter describes how Policy Assignments are handled by EPAC. Policy Assignments are the actual assignments of Policies and Policy Sets to scopes in Azure

Assignment JSON structure

Assignment JSON is hierarchical for efficient definitions, avoiding duplication (copy/paste) of JSON. Each branch of the tree is cumulative. Each tree node must include a nodeName - an arbitrary string exclusively used by EPAC to display an error location. EPAC concatenates a leading / and the nodeName entries encountered in the tree to create a "breadcrumbs" trail; therefore, we recommend that you use / to help separate the concatenated nodeName . The following partial and invalid assignment tree would create this error message.

JSON Schema

The GitHub repo contains a JSON schema which can be used in tools such as VS Code to provide code completion.

To utilize the schema add a $schema tag to the JSON file.

• Every tree branch must accumulate a definitionEntry (or definitionEntryList ), Assignment naming ( name and displayName ) and scope element.
• The elements parameters , overrides , resourceSelectors , notScope , enforcementMode , metadata , userAssignedIdentity , managedIdentityLocations , additionalRoleAssignments and nonComplianceMessages are optional.
• For Policy Sets with large numbers of included Policies you should use a spreadsheet (CSV file) to manage effects (parameterized or effect overrides ), parameters and optional nonComplianceMessages . We recommend the CSV approach for Policy Sets with more than 10 included Policies.
• EPAC continues to support deprecated elements initiativeId , initiativeName and ignoreBranch , Consider using their replacements policySetId , policySetName and enforcementMode instead.
• Role Assignments for user-assigned Managed Identities (UAMI) are not managed by EPAC, and will not generate a roles-plan.json file.
• additionalRoleAssignments are used when a resource required is not in the current scope. For example, a Policy Assignment that requires a Event Hub to be managed in a subscription not contained in the current management group.

The tree is not required to be balanced. The number of levels is not restricted; however, anything beyond 3 levels is unnecessary in real scenarios and would be difficult to read and manage as the depth increases.

Assignment Element and Metadata

Each Assignment is required to have a name which is used in it's resource id. EPAC also requires a displayName . The description is optional. For the allowed location assignment you specify the component with:

Multiple assignment naming components in a tree branch are string concatenated for each of the three fields.

Azure has a limit of 24 characters for the concatenated name string. EPAC displays an error if this limit is exceeded. Azure also has a limit of 128 characters for displayName and 512 characters for description (For additional information see Assignment Structure: Display name and description ).

Defining metadata

metadata is sometimes used to assign categories for changes. Do NOT specify EPAC-reserved elements roles and pacOwnerId . For the final metadata EPAC creates the union of instances in the entire tree branch.

Not recommended : Adding assignedBy to the metadata overrides the deployedBy value from the global-settings.jsonc file normally used for assignedBy . It defaults to "epac/$pacOwnerId/$pacSelector" .

Metadata for Role Assignments

Role assignments do not contain a metadata field. Instead, the description field is used to populate the deployedBy value. The description field is populated with the Policy Assignment Id, reason and deployedBy value. This is useful for tracking the source of the Role Assignment.

Reasons is one of:

• Role Assignment required by Policy - Policy definition(s) specify the required Role Definition Ids.
• additional Role Assignment - from filed "additionalRoleAssignments" in the Policy Assignment file.
• additional cross tenant Role Assignment - from filed "additionalRoleAssignments" with crossTenant set to $true in the Policy Assignment file.

Assigning Policy Sets or Policies

Assigning a single policy or policy set.

Each assignment assigns either a Policy or Policy Set. In EPAC this is done with a definitionEntry or a definitionEntryList . Exactly one occurrence must exist in any collated tree branch. For each entry, you need to specify one of the following:

• policyName - custom Policy. Specifying just the name allows EPAC to inject the correct definition scope.
• policySetName - custom Policy Set. Specifying just the name allows EPAC to inject the correct definition scope
• policyId - resource id for builtin Policy.
• policySetId - resource id for builtin Policy Set.

displayName is an optional field to document the entry if the Policy name is a GUID. Builtin Policies and Policy Sets use a GUID.

Assigning multiple Policies or Policy Sets

Using definitionEntryList allows you to save on copy/paste tree branches. Without it, the number of branches would need to be duplicated as many times as the list has entries.

Each entry in the list creates an Assignment at each leaf of the tree. Since assignments must have unique names at a specific scope, the Assignment naming component must be amended for each list entry. In this sub-component you can decide if you want to concatenate the string by appending or prepending them by specifying append boolean value.

In the above example one of the children (leaf node) has the following Assignment name.

This example generates two assignments at the "prod" leaf per scope:

• /providers/Microsoft.Management/managementGroups/ Contoso-Prod /providers/Microsoft.Authorization/policyAssignments/ pr-asb
• displayName = "Prod Azure Security Benchmark"
• description = "Prod Environment controls enforcement with Azure Security Benchmark Initiative."
• /providers/Microsoft.Management/managementGroups/ Contoso-Prod /providers/Microsoft.Authorization/policyAssignments/ pr-nist-800-53-r5
• displayName = "Prod NIST SP 800-53 Rev. 5"
• description = "Prod Environment controls enforcement with NIST SP 800-53 Rev. 5 Initiative."

scope is required exactly once in each tree branch. Excluded scopes ( notScope ) are cumulative from global-settings.json and the entire tree branch; however, once a scope is defined notScope may not be defined at any child node.

Both scope and notScope are specific to an EPAC Environment using the pacSelector name , e.g., epac-dev and tenant .

notScope works the same. In addition "*" means all EPAC Environments.

Managed Identities and role assignments

Policies with a DeployIfNotExists or Modify effect need a Managed Identity (MI) and role assignments to execute remediation task. EPAC calculates the necessary role assignments based on the roleDefinitionIds in the Policy definition. By default EPAC uses a system-assigned Manged Identity. The team maintaining EPAC recommend system-assigned identities; however, your organization may have role assignment reasons to use user-assigned Managed Identities.

Defining managedIdentityLocations

Policy assignments requiring a Managed Identity (system-assigned or user-assigned) require a location managedIdentityLocations . You must specify the location based on EPAC Environment or use "*" to use the same location for all of the EPAC Environments. You can specify them in global-settings.jsonc or at any node in the tree. The last (closest to the leaf node) is the one chosen if multiple managedIdentityLocations entries are encountered in a tree branch.

Defining optional additionalRoleAssignments

In some scenarios you will need additionalRoleAssignments ; e.g., for diagnostics settings to Event Hubs, the target resource might be in a different Management Group and therefore the Managed Identity requires additional role assignments. You must specify the additionalRoleAssignments based on EPAC Environment or use "*" to use the same additionalRoleAssignments for all of the EPAC Environments. If the pacEnvironment under deployment is specified in the additionalRoleAssignments, the "*" assignments will be ignored.

If the additional assignment is to made to a managing tenant in the sceenario where the pacEnvironment under deployment is a manganged (lighthouse) tenant, you must specify ""crossTenant": true" for that assignment. Ensure all necessary ABAC permissions are in place for the executing SPN.

User-assigned Managed Identities

Azure Policy can use a user-defined Managed Identity and EPAC allows you to use this functionality. You must specify the user-defined Managed Identity based on EPAC Environment or use "*" to use the same identity for all of the EPAC Environments (only possible in single tenant scenarios). Within each EPAC Environment entry, you can specify just the URI string indicating to use the same identity even if we are using a definitionEntryList , or in the case of a definitionEntryList can assign a different identity based on the definitionEntryList by specifying a matching policyName , policyId , policySetName or policySetId .

Defining parameters , overrides and nonComplianceMessages

Utilizing a csv file to define parameters , overrides and noncompliancemessages.

Assigning single or multiple security and compliance focused Policy Sets (Initiatives), such as Microsoft cloud security benchmark, NIST 800-53 R5, PCI, NIST 800-171, etc, with just JSON parameters becomes very complex fast. Add to this the complexity of overriding the effect if it is not surfaced as a parameter in the Policy Set . Finally, adding the optional nonComplianceMessages further increases the complexity.

To address the problem of reading and maintaining hundreds or thousands of JSON lines, EPAC can use the content of a spreadsheet (CSV) to create parameters , overrides and optionally nonComplianceMessages for a single Policy assignment definitionEntry or multiple Policy definitions ( definitionEntryList ).

This approach is best for large Policy Sets such as Azure Security Benchmark, NIST 800-53, etc. Smaller Policy Sets should still be handled with JSON parameters , overrides and nonComplianceMessages .

Implement these steps as documented in Managing Policy Assignment Parameters with a CSV file .

• Generate the CSV file form your already deployed Assignment(s) or Policy Set(s).
• Modify the effect and parameter columns for each type of environment types you will use.
• Modify the Policy Assignment file to reference the CSV file and the column prefix.
• Update the CSV file with the new effect and parameter values.

Defining parameters with JSON

parameters have a simplified JSON structure. You do not need the additional value indirection Azure requests (EPAC will inject that indirection).

Too enable definitionEntryList , parameters not present in the Policy or Policy Set definition are quietly ignored.

Advanced Elements

Defining overrides with json.

overrides are in the same format as documented by Azure . They are cumulative in each tree branch. The selectors element is only used for Assignments of Policy Sets. They are not valid for Assignments of a single Policy.

If using definitionEntryList , you must add the policyName , policyId , policySetName or policySetId as used in the definitionEntryList item.

Defining nonComplianceMessages with JSON

Assign a non-compliance message to the assignment, or individual non-compliance messages if the assignment is for an Policy Set. This value is an array of objects - each containing a message, and in the case of an initiative a policyDefinitionReferenceId. See this link for details.

If you use single definitionEntry , place them normally. If you use a definitionEntryList place them in the respective list entry.

Defining resourceSelectors

resourceSelectors may appear anywhere in the tree and are cumulative in any branch. They follow the standard Azure Format .

Defining enforcementMode

enforcementMode is similar to the deprecated ignoreBranch ; it deploys the assignment and sets the assignment to Default or DoNotEnforce . DoNotEnforce allows a what-if analysis. enforcementMode may appear anywhere in the tree. Definitions at a child override the previous setting.

Example assignment files

Simple policy assignment (allowed locations).

In the simple case an assignment is a single node with no difference in assignment , parameters , and definitionEntry across multiple scopes. In many scenarios "Allowed Locations" is such a simple Assignment. Such Assignments do not have child nodes, just the root node. Example

• nodeName is required for error messages; it's value is immaterial. EPAC concatenates them in the current tree branch.
• definitionEntry specifies that the custom Policy Set general-allowed-locations-policy-set from our starter kit. displayName has no meaning - it is for readability and in this instance is superfluous.
• assignment fields name , displayName and description are used when creating the assignment.
• This assignment has no metadata . You don't need an empty collection. EPAC will add pacOwnerId and roles metadata . Do not add them manually.
• enforcementMode is set to default - it is superfluous.
• parameters are obvious. Note: you don't add the value layer Azure inserts - EPAC takes care of that.
• During Policy resource development (called epac-dev ) the Assignment is deployed to an EPAC development Management Group Epac-Mg-1 .
• During Policy prod deployments ( tenant -wide), it is deployed to the tenant Management Group Epac-Mg-1 .
• No notScope entries are specified.

Security-Focused Policy Assignment with JSON parameters

• In the following example we named our root node ( nodeName ) /security/ . Since it is only used in case of error messages produced by EPAC during planning it's actual value doesn't matter as long as it's unique.
• We use a definitionEntryList to create two assignments at every leaf (six assignments total).
• For assignment string concatenation we append the strings in the definitionEntryList to the strings in the child nodes. You can see this best when you look at the description string in the child nodes. It will form a sentence when concatenated by append ing the definitionEntryList assignment field description .
• The parameters specified in the children are specific to the IaC environment types and their scope . Note: a real assignment would define many more parameters. The set here is abbreviated since the actual set could easily exceed a hundred entries for each of the IaC environments. We'll see in the next example how to simplify large Policy Set parameters with a CSV file.

Inverted Policy Assignment (Tag Inheritance and Required Tags)

As mentioned above sometimes it is advantageous (to reduce the number of repetitions) to turn a definition on its head:

• Common parameters , scope , definitionEntryList (with two Policies) at the root ( nodeName is /Tags/ ).
• Start of the assignment strings ( append is defaulted to false ). Again look at description which will be a concatenated sentence.
• The children define the tagName parameter and the second part of the strings for assignment . The set of parameters is the union of the root node and the child node.
• This creates six Assignments (number of Policies assigned times number of children).

Non-Compliance Messages in a Policy Definition Assignment

Non-compliance messages in a policy set definition assignment, non-compliance messages in a policy set definition assignment with a definitionentrylist.

• Stack Overflow for Teams Where developers & technologists share private knowledge with coworkers
• Advertising & Talent Reach devs & technologists worldwide about your product, service or employer brand
• OverflowAI GenAI features for Teams
• OverflowAPI Train & fine-tune LLMs
• Labs The future of collective knowledge sharing
• About the company Visit the blog

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Get early access and see previews of new features.

Azure policy not creating roles for managed identity when deployed through devOps

I created an azure policy via devops . I had a role enabled as given below(storage contributor). The identity was created for the policy but there was no role assigned to it. So I had to manually create it to run the remediation task. Shouldn't the policy create the role itself? or the deployment?

We deploy it as an arm template using New-AzDeployment

This is the full template

• azure-policy

• i have so many questions... please provide your arm template for the definition, initiative (if you have one) and the assignment. –  Rob S. Commented Jul 15, 2021 at 14:47
• 1 Edited the question to include it –  Blue Clouds Commented Jul 15, 2021 at 16:12
• This is definition. Wonder when the idenity role is added, on defintion creation or assignment –  Blue Clouds Commented Jul 15, 2021 at 16:12
• the role is added at assignment if done through the portal.. but if you do it via arm template you must provide a role assignment via arm template. –  Rob S. Commented Jul 15, 2021 at 17:55
• POLICY DEFINITION DEPLOYMENT
• (Optional) INITIATIVE DEFINTION DEPLOYMENT
• POLICY ASSIGNMENT DEPLOYMENT <- This is where you add your role assignment.

The role assignment must be made for the managed identity created by the policy assignment. If you create the policy assignment from the portal, I believe this is done automatically for you. An ARM template in DevOps will require a manual definition.

The policy assignment therefore must also be deployed with a role assignment.

I would recommend using a separate ARM template for assignments due to issues using "dependsOn" between definitions, initiatives, and assignments. Therefore your policy assignment template with the role assignment would stand alone and look something like the example template below.

I know it's not related to your question, but it's annoying enough to mention. In my experience, I've had to delay 2 minutes between definition deployments and subsequent initiative deployments and then another 2 minutes before assignment deployments in order to avoid 404 errors on dependencies.

• If this works please accept the answer or if not please let me know what your issue is so I can help. –  Rob S. Commented Jul 21, 2021 at 15:53

Your Answer

Reminder: Answers generated by artificial intelligence tools are not allowed on Stack Overflow. Learn more

Sign up or log in

Post as a guest.

Required, but never shown

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy .

Not the answer you're looking for? Browse other questions tagged azure azure-policy or ask your own question .

• The Overflow Blog
• Battling ticket bots and untangling taxes at the frontiers of e-commerce
• Ryan Dahl explains why Deno had to evolve with version 2.0
• Featured on Meta
• We've made changes to our Terms of Service & Privacy Policy - July 2024
• Bringing clarity to status tag usage on meta sites
• Feedback requested: How do you use tag hover descriptions for curating and do...

Hot Network Questions

• Does a cube under high pressure transform into a ball?
• If a body in free fall, according to general relativity is weightless, that is, not experiencing force, how does the object gain kinetic energy?
• Does "any computer(s) you have" refer to one or all the computers?
• How do I delete a systemd transient service like one created by systemd-run?
• Can there be clouds of free electrons in space?
• What prevents applications from misusing private keys?
• No Kippa while in a car
• What is the rationale behind requiring ATC to retire at age 56?
• What should I [34/F] do about my rude and mean supervisor [60s/F] when I want to finish my PhD?
• How old were Phineas and Ferb? What year was it?
• Where to locate vinyl window screws?
• Move line matching string to top of the file
• Are there any well-known political considerations for having a friend on the job market come for a visit and talk?
• Regression with a constant sharing a coefficient with an independent variable
• Can data be preprocessed when using EdDSA with SHAKE?
• Rounding vertices of polygon to fixed number of decimal places in QGIS
• How can I understand op-amp operation modes?
• How common is it for external contractors to manage internal teams, and how can we navigate this situation?
• Is there a good explanation for the existence of the C19 globular cluster with its very low metallicity?
• A natural automorphism of a finite group with two generators?
• In a doubly robust learner, do the covariates need to be the same for the outcome model and the propensity model?
• Creating a deadly "minimum altitude limit" in an airship setting
• Book in which a hunter from Texas is transported to a magical world where he becomes the protector of two infant dragons
• Is "UN law" a thing?

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

Policy assignment in bicep which require managed identities #5825

bk-edge Feb 1, 2022

Beta Was this translation helpful? Give feedback.

You will need to assign a managed identity to the policy assignment.

See the Bicep spec for this resource here: https://docs.microsoft.com/en-us/azure/templates/microsoft.authorization/policyassignments?tabs=bicep

If you want to create a system assigned you need to use the identity property:

Note that you will need to create corresponding role assignme…

Replies: 1 comment · 1 reply

{{editor}}'s edit, matsest feb 1, 2022.

bk-edge Feb 1, 2022 Author

• Numbered list
• Unordered list
• Attach files

Select a reply

Policy Assignment and managed identity

Hi everyone

My assignment looks like this:

resource “azurerm_policy_assignment” “AssRGTags” { name = “AssRGTags” scope = azurerm_management_group.mymanagementgroup.id policy_definition_id = azurerm_policy_set_definition.level01RGTagsHeredity.id description = “Policy Assignment RG Tag Heredity” display_name = “AssRGTagsHeredityDevInt” location = “westeurope”

The Definition and the Assignment looks very well, but if i try to start a “Remediation Task”, following Error-Message appears:

The managed identity for this assignment does not have the appropriate permissions to remediate these resources. To add these permissions, go to the Edit Assignment page for this Policy and re-save it.

How can i deploy an Assignment with the proper Permissons set?

thanx for any Ideas …

Were you able to fix this?

…i’m also experiencing the same issue. any fix to this?

Long story short: If you deploy Azure Policy/ Azure Initiative assignment at Azure Management Group level in non-portal way (ARM Templates/ Terraform Then take care of role assignment for MSI created during an assignment on your own.

The best way is to assign a role at required scope by using: https://www.terraform.io/docs/providers/azurerm/r/role_assignment.html

I wrote an article explaining other workaround ways here: https://automate.guru/fix-msi-role-assignment/

• Articles detail /

NPO (Health System Policy & Evaluation) - (2406299)

IMPORTANT NOTICE:  Please note that the deadline for receipt of applications indicated above reflects your personal device's system settings.

OBJECTIVES OF THE PROGRAMME

The objectives of the programme include: 1) conducting evidence syntheses on policy interventions to maximize efficiency, access and quality of essential health services and identifying suitable policy options for health system reforms; 2) strengthening national capacities to develop health policies, strategies and plans within the context of UHC and SDG which reflect the country's unique epidemiological and demographic profile, the level of economic and social development, status of health system, population's demands and expectations and partnership environment;3) improving the service delivery to ensure PHC-oriented health system delivers integrated, equitable, high-impact and people-centered health services with financial protection and resilience to address people's needs; and 4) conducting regular evaluation and analysis of national and subnational health systems and trends using comparable methods

DESCRIPTION OF DUTIES

Under the overall guidance of WHO Representative and direct supervision of Public Health Administrator the incumbent will have the following responsibilities:

1. Provide assistance to Ministry of Health on the development, implementation, and evaluation of national health policies, strategies and plans and assist in technical consultations and policy dialogues.

2. Facilitate the organization of regular participatory mechanisms for assessing the health situation, evaluating of health system areas, and formulating strategic recommendations related to the health system components.

3. Coordinate conducting of evidence syntheses on policy interventions to maximize efficiency, access and quality of essential health services and identifying suitable policy options for health system reforms.

4. Provide technical assistance related to the Integrated Health System matters mainly focusing on health services development, integrated health care delivery networks, quality of care and inter-programmatic initiatives on NCDs, family, gender and life course approaches.

5. Assist in developing tools, guidelines and innovative approaches related to evidence-informed policies on primary health care -shared care cluster system to strengthen the national health care system by expanding access to primary health care for tackling inequities and addressing broader determinants of health.

6. Support in developing and designing of performance measurement and evaluation framework, including resources needed for analyzing and interpreting data and implementing corrective actions for quality assurance, and management and improvement of the shared care cluster system for primary care.

7. Provide technical assistance in developing and implementing of human resources for health policies, strategies and plans to ensure equitable access to health services including primary health care and organize capacity building of the health care workers to meet the healthcare challenges.

8. Provide technical support to conduct health technology assessments, and develop health financing strategies.

9. Provide technical advice and support to national health authorities in innovative service delivery models which can address changing health needs including NCDs and needs of ageing populations.

10. Support in development and implementation of strategies for improving patient safety and quality of health services at the national level within the context of universal health coverage.

11. Collaborate in the preparation of the Biennial Work Plan (BWP) and the execution of national technical cooperation, including the analysis of political, technical and socioeconomic realities.

12. Draft necessary technical reports and documents as per requirements of the Organization, and to assist in preparation, organization and following-up of WHO-organized meetings.

13. Undertake any other related duties as assigned by the supervisors.

REQUIRED QUALIFICATIONS

Essential : Bachelor's degree in public health or medicine from a recognized university. Desirable : Professional training in evaluation, policy analysis, health system analysis, epidemiology, information management systems, and/or health programme management.

Essential : At least 5 years of relevant working experience at the national or sub-national level in monitoring and evaluation of programmes, policy analysis, planning/programming, research and health system analysis. Desirable : Experience in establishing harmonious relationships with partners, within and outside of government. Familiarity with UN system in general and WHO in particular. Proven track record in managing primary care projects, developing evidence and operational research projects.

Good knowledge and experience in health policy and strategies, Health system evaluation and analysis, advance research methodologies, statistics, Health surveys and mapping. Skills in programme planning/development, health workforce training, monitoring/evaluation of interventions and in development of locally-adapted tools and instruments. Familiarity with functioning of government and its institutions. Good communication skills with proven aptitude for effective verbal and written communication. Ability to interact with health professionals at various levels. Ability to think strategically and work under tight deadlines on a results-oriented basis. Ability to develop innovative approaches and solutions. Ability to motivate and manage colleagues to engage in broader aspects of work as part of a team beyond individual areas of work. Ability to demonstrate effective interpersonal skills by working harmoniously as a member of a team, adapting to diverse educational, socio-political and cultural backgrounds and maintaining a high standard of personal conduct.

WHO Competencies

• Respecting and promoting individual and cultural differences
• Communication
• Building and promoting partnerships across the organization and beyond
• Ensuring the effective use of resources
• Creating an empowering and motivating environment

Use of Language Skills

Essential : Expert knowledge of English. Expert knowledge of Sinhalese/Tamil.

REMUNERATION

Remuneration comprises an annual base salary starting at LKR 9,074,832 (subject to mandatory deductions for pension contributions and health insurance, as applicable) and 30 days of annual leave.

ADDITIONAL INFORMATION

• This vacancy notice may be used to fill other similar positions at the same grade level.
• Only candidates under serious consideration will be contacted.
• A written test and/or an asynchronous video assessment may be used as a form of screening.
• In the event that your candidature is retained for an interview, you will be required to provide, in advance, a scanned copy of the degree(s)/diploma(s)/certificate(s) required for this position. WHO only considers higher educational qualifications obtained from an institution accredited/recognized in the World Higher Education Database (WHED), a list updated by the International Association of Universities (IAU)/United Nations Educational, Scientific and Cultural Organization (UNESCO). The list can be accessed through the link:  http://www.whed.net/ . Some professional certificates may not appear in the WHED and will require individual review.
• According to article 101, paragraph 3, of the Charter of the United Nations, the paramount consideration in the employment of the staff is the necessity of securing the highest standards of efficiency, competence, and integrity. Due regard will be paid to the importance of recruiting the staff on as wide a geographical basis as possible.
• Any appointment/extension of appointment is subject to WHO Staff Regulations, Staff Rules and Manual.
• The WHO is committed to creating a diverse and inclusive environment of mutual respect. The WHO recruits and employs staff regardless of disability status, sex, gender identity, sexual orientation, language, race, marital status, religious, cultural, ethnic and socio-economic backgrounds, or any other personal characteristics.
• The WHO is committed to achieving gender parity and geographical diversity in its staff. Women, persons with disabilities, and nationals of unrepresented and underrepresented Member States ( https://www.who.int/careers/diversity-equity-and-inclusion ) are strongly encouraged to apply.
• Persons with disabilities can request reasonable accommodations to enable participation in the recruitment process. Requests for reasonable accommodation should be sent through an email to  [email protected]
• An impeccable record for integrity and professional ethical standards is essential. WHO prides itself on a workforce that adheres to the highest ethical and professional standards and that is committed to put the  WHO Values Charter  into practice.
• WHO has zero tolerance towards sexual exploitation and abuse (SEA), sexual harassment and other types of abusive conduct (i.e., discrimination, abuse of authority and harassment). All members of the WHO workforce have a role to play in promoting a safe and respectful workplace and should report to WHO any actual or suspected cases of SEA, sexual harassment and other types of abusive conduct. To ensure that individuals with a substantiated history of SEA, sexual harassment or other types of abusive conduct are not hired by the Organization, WHO will conduct a background verification of final candidates.
• WHO has a smoke-free environment and does not recruit smokers or users of any form of tobacco.
• For information on WHO's operations please visit:  http://www.who.int.
• WHO also offers wide range of benefits to staff, including parental leave and attractive flexible work arrangements to help promote a healthy work-life balance and to allow all staff members to express and develop their talents fully.
• The statutory retirement age for staff appointments is 65 years. For external applicants, only those who are expected to complete the term of appointment will normally be considered.
• Please note that WHO's contracts are conditional on members of the workforce confirming that they are vaccinated as required by WHO before undertaking a WHO assignment, except where a medical condition does not allow such vaccination, as certified by the WHO Staff Health and Wellbeing Services (SHW). The successful candidate will be asked to provide relevant evidence related to this condition. A copy of the updated vaccination card must be shared with WHO medical service in the medical clearance process. Please note that certain countries require proof of specific vaccinations for entry or exit. For example, official proof /certification of yellow fever vaccination is required to enter many countries. Country-specific vaccine recommendations can be found on the WHO international travel and Staff Health and Wellbeing website. For vaccination-related queries please directly contact SHW directly at  [email protected] .
• This is a National Professional Officer position. Therefore, only applications from nationals of the country where the duty station is located will be accepted. Applicants who are not nationals of this country will not be considered.
• In case the website does not display properly, please retry by: (i) checking that you have the latest version of the browser installed (Chrome, Edge or Firefox); (ii) clearing your browser history and opening the site in a new browser (not a new tab within the same browser); or (iii) retry accessing the website using Mozilla Firefox browser or using another device. Click this link for detailed guidance on completing job applications:  Instructions for candidates

Link to apply:

• WHO Careers Website:  Careers at WHO
• Vacancies (staff member access):  https://careers.who.int/careersection/in/jobsearch.ftl  
• Vacancies (external candidate access):  https://careers.who.int/careersection/ex/jobsearch.ftl

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Managed identity best practice recommendations

• 14 contributors

Managed identities for Azure resources is a feature of Microsoft Entra ID. Each of the Azure services that support managed identities for Azure resources are subject to their own timeline. Make sure you review the availability status of managed identities for your resource and known issues before you begin.

Choosing system or user-assigned managed identities

User-assigned managed identities are more efficient in a broader range of scenarios than system-assigned managed identities. See the table below for some scenarios and the recommendations for user-assigned or system-assigned.

User-assigned identities can be used by multiple resources, and their life cycles are decoupled from the resources’ life cycles with which they’re associated. Read which resources support managed identities .

This life cycle allows you to separate your resource creation and identity administration responsibilities. User-assigned identities and their role assignments can be configured in advance of the resources that require them. Users who create the resources only require the access to assign a user-assigned identity, without the need to create new identities or role assignments.

As system-assigned identities are created and deleted along with the resource, role assignments can't be created in advance. This sequence can cause failures while deploying infrastructure if the user creating the resource doesn't also have access to create role assignments.

If your infrastructure requires that multiple resources require access to the same resources, a single user-assigned identity can be assigned to them. Administration overhead will be reduced, as there are fewer distinct identities and role assignments to manage.

If you require that each resource has its own identity, or have resources that require a unique set of permissions and want the identity to be deleted as the resource is deleted, then you should use a system-assigned identity.

Using user-assigned identities to reduce administration

The diagrams demonstrate the difference between system-assigned and user-assigned identities, when used to allow several virtual machines to access two storage accounts.

The diagram shows four virtual machines with system-assigned identities. Each virtual machine has the same role assignments that grants them access to two storage accounts.

When a user-assigned identity is associated with the four virtual machines, only two role assignments are required, compared to eight with system-assigned identities. If the virtual machines' identity requires more role assignments, they'll be granted to all the resources associated with this identity.

Security groups can also be used to reduce the number of role assignments that are required. This diagram shows four virtual machines with system-assigned identities, which have been added to a security group, with the role assignments added to the group instead of the system-assigned identities. While the result is similar, this configuration doesn't offer the same Resource Manager template capabilities as user-assigned identities.

Multiple managed identities

Resources that support managed identities can have both a system-assigned identity and one or more user-assigned identities.

This model provides the flexibility to both use a shared user-assigned identity and apply granular permissions when needed.

In the example below, “Virtual Machine 3” and “Virtual Machine 4” can access both storage accounts and key vaults, depending on which user-assigned identity they use while authenticating.

In the example below, “Virtual Machine 4” has both a user-assigned identity, giving it access to both storage accounts and key vaults, depending on which identity is used while authenticating. The role assignments for the system-assigned identity are specific to that virtual machine.

View the limits for managed identities and for custom roles and role assignments .

Follow the principle of least privilege when granting access

When granting any identity, including a managed identity, permissions to access services, always grant the least permissions needed to perform the desired actions. For example, if a managed identity is used to read data from a storage account, there is no need to allow that identity permissions to also write data to the storage account. Granting extra permissions, for example, making the managed identity a contributor on an Azure subscription when it’s not needed, increases the security blast radius associated with the identity. One must always minimize the security blast radius so that compromising that identity causes minimum damage.

Consider the effect of assigning managed identities to Azure resources and/or granting assign permissions to a user

It is important to note that when an Azure resource, such as an Azure Logic App, an Azure function, or a Virtual Machine, and so on. is assigned a managed identity, all the permissions granted to the managed identity are now available to the Azure resource. This is important because if a user has access to install or execute code on this resource, then the user has access to all the identities assigned/associated to the Azure resource. The purpose of managed identity is to give code running on an Azure resource access to other resources, without developers needing to handle or put credentials directly into code to get that access.

For example, if a managed Identity (ClientId = 1234) has been granted read/write access to StorageAccount7755 and has been assigned to LogicApp3388 , then Alice, who does not have direct access to the storage account but has permission to execute code within LogicApp3388 can also read/write data to/from StorageAccount7755 by executing the code that uses the managed identity.

Similarly, if Alice has permissions to assign the managed identity herself, she can assign it to a different Azure resource and have access to all the permissions available to the managed identity.

In general, when granting a user administrative access to a resource that can execute code (such as a Logic App) and has a managed identity, consider if the role being assigned to the user can install or run code on the resource, and if yes only assign that role if the user really needs it.

Maintenance

System-assigned identities are automatically deleted when the resource is deleted, while the lifecycle of a user-assigned identity is independent of any resources with which it's associated.

You'll need to manually delete a user-assigned identity when it's no longer required, even if no resources are associated with it.

Role assignments aren't automatically deleted when either system-assigned or user-assigned managed identities are deleted. These role assignments should be manually deleted so the limit of role assignments per subscription isn't exceeded.

Role assignments that are associated with deleted managed identities will be displayed with “Identity not found” when viewed in the portal. Read more .

Role assignments which are no longer associated with a user or service principal will appear with an ObjectType value of Unknown . In order to remove them, you can pipe several Azure PowerShell commands together to first get all the role assignments, filter to only those with an ObjectType value of Unknown and then remove those role assignments from Azure.

Limitation of using managed identities for authorization

Using Microsoft Entra ID groups for granting access to services is a great way to simplify the authorization process. The idea is simple – grant permissions to a group and add identities to the group so that they inherit the same permissions. This is a well-established pattern from various on-premises systems and works well when the identities represent users. Another option to control authorization in Microsoft Entra ID is by using App Roles , which allows you to declare roles that are specific to an app (rather than groups, which are a global concept in the directory). You can then assign app roles to managed identities (as well as users or groups).

In both cases, for non-human identities such as Microsoft Entra Applications and Managed identities, the exact mechanism of how this authorization information is presented to the application is not ideally suited today. Today's implementation with Microsoft Entra ID and Azure Role Based Access Control (Azure RBAC) uses access tokens issued by Microsoft Entra ID for authentication of each identity. If the identity is added to a group or role, this is expressed as claims in the access token issued by Microsoft Entra ID. Azure RBAC uses these claims to further evaluate the authorization rules for allowing or denying access.

Given that the identity's groups and roles are claims in the access token, any authorization changes do not take effect until the token is refreshed. For a human user that's typically not a problem, because a user can acquire a new access token by logging out and in again (or waiting for the token lifetime to expire, which is 1 hour by default). Managed identity tokens on the other hand are cached by the underlying Azure infrastructure for performance and resiliency purposes: the back-end services for managed identities maintain a cache per resource URI for around 24 hours. This means that it can take several hours for changes to a managed identity's group or role membership to take effect. Today, it is not possible to force a managed identity's token to be refreshed before its expiry. If you change a managed identity’s group or role membership to add or remove permissions, you may therefore need to wait several hours for the Azure resource using the identity to have the correct access.

If this delay is not acceptable for your requirements, consider alternatives to using groups or roles in the token. To ensure that changes to permissions for managed identities take effect quickly, we recommend that you group Azure resources using a user-assigned managed identity with permissions applied directly to the identity, instead of adding to or removing managed identities from a Microsoft Entra group that has permissions. A user-assigned managed identity can be used like a group because it can be assigned to one or more Azure resources to use it. The assignment operation can be controlled using the Managed identity contributor and Managed identity operator role .

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources