You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/active-directory/develop/scenario-daemon-app-configuration.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ Daemon applications use application permissions rather than delegated permission
31
31
32
32
The authority specified in the application configuration should be tenanted (specifying a tenant ID or a domain name associated with your organization).
33
33
34
-
Even if want to provide a multitenant tool, you should use a tenant ID or domain name, and **not**`common` or `organizations` with this flow, because the service cannot reliably infer which tenant should be used.
34
+
Even if you want to provide a multitenant tool, you should use a tenant ID or domain name, and **not**`common` or `organizations` with this flow, because the service cannot reliably infer which tenant should be used.
Copy file name to clipboardExpand all lines: articles/active-directory/develop/workload-identity-federation-create-trust-github.md
+64-3Lines changed: 64 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ ms.service: active-directory
10
10
ms.subservice: develop
11
11
ms.topic: how-to
12
12
ms.workload: identity
13
-
ms.date: 10/18/2021
13
+
ms.date: 01/28/2022
14
14
ms.author: ryanwi
15
15
ms.custom: aaddev
16
16
ms.reviewer: keyam, udayh, vakarand
@@ -44,7 +44,7 @@ In the **Federated credential scenario** drop-down box select **GitHub actions d
44
44
45
45
Specify the **Organization** and **Repository** for your GitHub Actions workflow.
46
46
47
-
For **Entity type**, select **Environment**, **Branch**, **Pull request**, or **Tag** and specify the value.
47
+
For **Entity type**, select **Environment**, **Branch**, **Pull request**, or **Tag** and specify the value. The values must exactly match the configuration in the [GitHub workflow](https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions#on). For more info, read the [examples](#entity-type-examples).
48
48
49
49
Add a **Name** for the federated credential.
50
50
@@ -60,6 +60,67 @@ Click **Add** to configure the federated credential.
60
60
> [!IMPORTANT]
61
61
> The **Organization**, **Repository**, and **Entity type** values must exactly match the configuration on the GitHub workflow configuration. Otherwise, Microsoft identity platform will look at the incoming external token and reject the exchange for an access token. You won't get an error, the exchange fails without error.
62
62
63
+
### Entity type examples
64
+
65
+
#### Branch example
66
+
67
+
For a workflow triggered by a push or pull request event on the main branch:
68
+
69
+
```yml
70
+
on:
71
+
push:
72
+
branches: [ main ]
73
+
pull_request:
74
+
branches: [ main ]
75
+
```
76
+
77
+
Specify an **Entity type** of **Branch** and a **GitHub branch name** of "main".
78
+
79
+
#### Environment example
80
+
81
+
For Jobs tied to an environment named "production":
82
+
83
+
```yml
84
+
on:
85
+
push:
86
+
branches:
87
+
- main
88
+
89
+
jobs:
90
+
deployment:
91
+
runs-on: ubuntu-latest
92
+
environment: production
93
+
steps:
94
+
- name: deploy
95
+
# ...deployment-specific steps
96
+
```
97
+
98
+
Specify an **Entity type** of **Environment** and a **GitHub environment name** of "production".
99
+
100
+
#### Tag example
101
+
102
+
For example, for a workflow triggered by a push to the tag named "v2":
103
+
104
+
```yml
105
+
on:
106
+
push:
107
+
# Sequence of patterns matched against refs/heads
108
+
branches:
109
+
- main
110
+
- 'mona/octocat'
111
+
- 'releases/**'
112
+
# Sequence of patterns matched against refs/tags
113
+
tags:
114
+
- v2
115
+
- v1.*
116
+
```
117
+
118
+
Specify an **Entity type** of **Tag** and a **GitHub tag name** of "v2".
119
+
120
+
#### Pull request example
121
+
122
+
For a workflow triggered by a pull request event, specify an **Entity type** of **Pull request**.
123
+
63
124
# [Microsoft Graph](#tab/microsoft-graph)
64
125
Launch [Azure Cloud Shell](https://portal.azure.com/#cloudshell/) and sign in to your tenant.
65
126
@@ -145,6 +206,6 @@ az rest -m DELETE -u 'https://graph.microsoft.com/beta/applications/f6475511-fd
145
206
Before configuring your GitHub Actions workflow, get the *tenant-id* and *client-id* values of your app registration. You can find these values in the Azure portal. Go to the list of [registered applications](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps) and select your app registration. In **Overview**->**Essentials**, find the **Application (client) ID** and **Directory (tenant) ID**. Set these values in your GitHub environment to use in the Azure login action for your workflow.
146
207
147
208
## Next steps
148
-
[Configure a GitHub Actions workflow](/azure/developer/github/connect-from-azure) to get an access token from Microsoft identity provider and access Azure resources.
209
+
For an end-to-end example, read [Deploy to App Service using GitHub Actions](/azure/app-service/deploy-github-actions?tabs=openid).
149
210
150
211
Read the [GitHub Actions documentation](https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure) to learn more about configuring your GitHub Actions workflow to get an access token from Microsoft identity provider and access Azure resources.
# What are managed identities for Azure resources?
23
23
24
-
A common challenge for developers is the management of secrets and credentials used to secure communication between different components making up a solution. Managed identities eliminate the need for developers to manage credentials. Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. Applications may use the managed identity to obtain Azure AD tokens. For example, an application may use a managed identity to access resources like [Azure Key Vault](../../key-vault/general/overview.md) where developers can store credentials in a secure manner or to access storage accounts.
24
+
A common challenge for developers is the management of secrets and credentials used to secure communication between different components making up a solution. Managed identities eliminate the need for developers to manage credentials.
25
25
26
-
Take a look at how you can use managed identities</br>
26
+
Managed identities provide an identity for applications to use when connecting to resources that support Azure Active Directory (Azure AD) authentication. Applications may use the managed identity to obtain Azure AD tokens. With [Azure Key Vault](../../key-vault/general/overview.md), developers can use managed identities to access resources. Key Vault stores credentials in a secure manner and gives access to storage accounts.
27
+
28
+
The following video shows how you can use managed identities:</br>
Here are some of the benefits of using Managed identities:
34
+
Here are some of the benefits of using managed identities:
33
35
34
-
- You don't need to manage credentials. Credentials are not even accessible to you.
35
-
- You can use managed identities to authenticate to any resource that supports [Azure Active Directory authentication](../authentication/overview-authentication.md) including your own applications.
36
+
- You don't need to manage credentials. Credentials aren’t even accessible to you.
37
+
- You can use managed identities to authenticate to any resource that supports [Azure AD authentication](../authentication/overview-authentication.md), including your own applications.
36
38
- Managed identities can be used without any additional cost.
37
39
38
40
> [!NOTE]
@@ -42,53 +44,55 @@ Here are some of the benefits of using Managed identities:
42
44
43
45
There are two types of managed identities:
44
46
45
-
-**System-assigned** Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity an identity is created in Azure AD that is tied to the lifecycle of that service instance. So when the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.
46
-
-**User-assigned** You may also create a managed identity as a standalone Azure resource. You can [create a user-assigned managed identity](how-to-manage-ua-identity-portal.md) and assign it to one or more instances of an Azure service. In the case of user-assigned managed identities, the identity is managed separately from the resources that use it. </br></br>
47
+
-**System-assigned**. Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity, an identity is created in Azure AD. The identity is tied to the lifecycle of that service instance. When the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.
48
+
-**User-assigned**. You may also create a managed identity as a standalone Azure resource. You can [create a user-assigned managed identity](how-to-manage-ua-identity-portal.md) and assign it to one or more instances of an Azure service. For user-assigned managed identities, the identity is managed separately from the resources that use it. </br></br>
47
49
48
50
49
-
The table below shows the differences between the two types of managed identities.
51
+
The following table shows the differences between the two types of managed identities:
| Creation | Created as part of an Azure resource (for example, an Azure virtual machine or Azure App Service) | Created as a stand-alone Azure resource |
55
+
| Creation | Created as part of an Azure resource (for example, Azure Virtual Machines or Azure App Service).| Created as a stand-alone Azure resource.|
54
56
| Life cycle | Shared life cycle with the Azure resource that the managed identity is created with. <br/> When the parent resource is deleted, the managed identity is deleted as well. | Independent life cycle. <br/> Must be explicitly deleted. |
55
-
| Sharing across Azure resources |Cannot be shared. <br/> It can only be associated with a single Azure resource. | Can be shared <br/> The same user-assigned managed identity can be associated with more than one Azure resource. |
56
-
| Common use cases | Workloads that are contained within a single Azure resource <br/> Workloads for which you need independent identities. <br/> For example, an application that runs on a single virtual machine | Workloads that run on multiple resources and which can share a single identity. <br/> Workloads that need pre-authorization to a secure resource as part of a provisioning flow. <br/> Workloads where resources are recycled frequently, but permissions should stay consistent. <br/> For example, a workload where multiple virtual machines need to access the same resource |
57
+
| Sharing across Azure resources |Can’t be shared. <br/> It can only be associated with a single Azure resource. | Can be shared. <br/> The same user-assigned managed identity can be associated with more than one Azure resource. |
58
+
| Common use cases | Workloads that are contained within a single Azure resource. <br/> Workloads for which you need independent identities. <br/> For example, an application that runs on a single virtual machine.| Workloads that run on multiple resources and can share a single identity. <br/> Workloads that need pre-authorization to a secure resource, as part of a provisioning flow. <br/> Workloads where resources are recycled frequently, but permissions should stay consistent. <br/> For example, a workload where multiple virtual machines need to access the same resource.|
57
59
58
60
> [!IMPORTANT]
59
-
> Regardless of the type of identity chosen a managed identity is a service principal of a special type that may only be used with Azure resources. When the managed identity is deleted, the corresponding service principal is automatically removed.
61
+
> Regardless of the type of identity chosen, a managed identity is a service principal of a special type that can only be used with Azure resources. When the managed identity is deleted, the corresponding service principal is automatically removed.
62
+
63
+
<br/>
60
64
61
65
## How can I use managed identities for Azure resources?
62
66
63
-
67
+
[](media/overview/when-use-managed-identities.png#lightbox)
64
68
65
69
## What Azure services support the feature?<aname="which-azure-services-support-managed-identity"></a>
66
70
67
-
Managed identities for Azure resources can be used to authenticate to services that support Azure AD authentication. For a list of Azure services that support the managed identities for Azure resources feature, see [Services that support managed identities for Azure resources](./services-support-managed-identities.md).
71
+
Managed identities for Azure resources can be used to authenticate to services that support Azure AD authentication. For a list of supported Azure services, see [services that support managed identities for Azure resources](./services-support-managed-identities.md).
68
72
69
73
## Which operations can I perform using managed identities?
70
74
71
75
Resources that support system assigned managed identities allow you to:
72
76
73
77
- Enable or disable managed identities at the resource level.
74
-
- Use RBAC roles to [grant permissions](howto-assign-access-portal.md).
- View sign-in activity in Azure AD [sign-in logs](../reports-monitoring/concept-sign-ins.md).
78
+
- Use role-based access control (RBAC) to [grant permissions](howto-assign-access-portal.md).
79
+
- View the create, read, update, and delete (CRUD) operations in [Azure Activity logs](../../azure-monitor/essentials/activity-log.md).
80
+
- View signin activity in Azure AD [signin logs](../reports-monitoring/concept-sign-ins.md).
77
81
78
82
If you choose a user assigned managed identity instead:
79
83
80
-
- You can [create, read, update, delete](how-to-manage-ua-identity-portal.md) the identities.
84
+
- You can [create, read, update, and delete](how-to-manage-ua-identity-portal.md) the identities.
81
85
- You can use RBAC role assignments to [grant permissions](howto-assign-access-portal.md).
82
86
- User assigned managed identities can be used on more than one resource.
83
87
- CRUD operations are available for review in [Azure Activity logs](../../azure-monitor/essentials/activity-log.md).
84
-
- View sign-in activity in Azure AD [sign-in logs](../reports-monitoring/concept-sign-ins.md).
88
+
- View signin activity in Azure AD [signin logs](../reports-monitoring/concept-sign-ins.md).
85
89
86
-
Operations on managed identities may be performed by using an Azure Resource Manager (ARM) template, the Azure portal, the Azure CLI, PowerShell, and REST APIs.
90
+
Operations on managed identities can be performed by using an Azure Resource Manager template, the Azure portal, Azure CLI, PowerShell, and REST APIs.
87
91
88
92
## Next steps
89
93
90
94
*[Use a Windows VM system-assigned managed identity to access Resource Manager](tutorial-windows-vm-access-arm.md)
91
95
*[Use a Linux VM system-assigned managed identity to access Resource Manager](tutorial-linux-vm-access-arm.md)
92
96
*[How to use managed identities for App Service and Azure Functions](../../app-service/overview-managed-identity.md)
93
97
*[How to use managed identities with Azure Container Instances](../../container-instances/container-instances-managed-identity.md)
94
-
*[Implementing Managed Identities for Microsoft Azure Resources](https://www.pluralsight.com/courses/microsoft-azure-resources-managed-identities-implementing).
98
+
*[Implementing managed identities for Microsoft Azure Resources](https://www.pluralsight.com/courses/microsoft-azure-resources-managed-identities-implementing)
0 commit comments