Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix 1755 #1777

Merged
merged 18 commits into from
Sep 14, 2021
Merged

Fix 1755 #1777

merged 18 commits into from
Sep 14, 2021

Conversation

ItalyPaleAle
Copy link
Contributor

@ItalyPaleAle ItalyPaleAle commented Sep 10, 2021

Thank you for helping make the Dapr documentation better!

Please follow this checklist before submitting:

  • Read the contribution guide
  • Commands include options for Linux, MacOS, and Windows within codetabs
  • New file and folder names are globally unique
  • Page references use shortcodes instead of markdown or URL links
  • N/A Images use HTML style and have alternative text
  • Places where multiple code/command options are given have codetabs

Description

This PR addresses #1755.

As of writing, this is still a WIP:

Issue reference

#1755

@ItalyPaleAle ItalyPaleAle changed the base branch from v1.3 to v1.4 September 10, 2021 01:13
@ItalyPaleAle
Copy link
Contributor Author

@orizohar @berndverst Here's the first work on the docs as discussed in #1755

It's my first contribution to the Dapr docs and it's a fairly large one, so even before I write the docs for the last component, your help as reviewers would be highly appreciated, to ensure that I've followed the right style.

Some of these things aren't super easy to explain, including all of the Azure AD parts... I've tried to clean up the AKV docs which were mixing concepts related to AKV and some related to AAD.

The result is less like a straightforward "do 1, 2, 3 and you're done", but it offers better security (using az ad sp create-for-rbac as was recommended before creates a SP that has access to manage EVERY resource in the Azure subscription - and that's even useless for Dapr since we need data plane access) and more flexibility because the same SP can be used for multiple Azure components.

Also, cc @cmatskas to keep me accountable and make sure I've documented AAD topics correctly

Copy link

@cmatskas cmatskas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small feedback but overall it looks great

type: docs
title: "Authenticating to Azure"
linkTitle: "Authenticating to Azure"
description: "How to authenticate Azure components using Azure AD and Managed Identities"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Azure Active Directory

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No in this case it should be "Azure" because it's for components authenticating with Azure. Also, for symmetry with the AWS one: https://docs.dapr.io/developing-applications/integrations/cloud-providers/


Many of the services listed above also support authentication using other systems, such as "master keys" or "shared keys". Although those are always valid methods to authenticate your application (and Dapr continues to support them, as explained in each component's reference page), using Azure AD when possible offers various benefits, including:

- The ability to leverage Managed Service Identities, which allow your application to authenticate with Azure AD, and obtain an access token to make requests to Azure services, without the need to use any credential. When your application is running on a supported Azure service (including, but not limited to, Azure VMs, Azure Kubernetes Service, Azure Web Apps, etc), an identity for your application can be assigned at the infrastructure level. This way, your code does not have to deal with credentials of any kind, removing the challenge of safely managing credentials, allowing greater separation of concerns between development and operations teams and reducing the number of people with access to credentials, and lastly simplifying operational aspects–especially when multiple environments are used.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Azure Arc - joined devices also provide support for Managed Identities so the solution doesn't have to run on Azure to benefit from this security feature.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if Dapr supports Arc at this time. @berndverst and I were talking about that but there may be other issues with Arc...

> az account set -s [your subscription id]
> ```

First, create the Azure AD application with:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can oversimplify this by using the az ad sp create-for-rbac --role Contributor --scopes <optional>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Dapr still need an App Registration to authenticate to AAD? if that's the case, ignore above comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes Dapr does need the App Registration to authenticate with AAD. I also would prefer not using the short-hand comment because the SP doesn't need any access at the entire subscription level.


Keep in mind that the Service Principal we just created does not have access to any Azure resource by default. Access will need to be granted to each resource as needed, as documented in the docs for the components.

> Note: this step is different from the [official documentation](https://docs.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli) as the short-hand commands create a Service Principal that has broad read-write access to all Azure resources in your subscription. Not only this grants our application more access than you are likely going to desire, but this also applies only to the Azure management plane (Azure Resource Manager, or ARM), which is irrelevant for Dapr anyways (all Azure components are designed to interact with the data plane of various services, and not ARM).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can pass the scope you want during the creation of the SP using the --scopes parameter

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See my comment above. The SP shouldn't have any access at the subscription level, it only needs data plane access and that should be granted at the resource level (for the principle of the least privileges)

@orizohar
Copy link

@orizohar @berndverst Here's the first work on the docs as discussed in #1755

It's my first contribution to the Dapr docs and it's a fairly large one, so even before I write the docs for the last component, your help as reviewers would be highly appreciated, to ensure that I've followed the right style.

Some of these things aren't super easy to explain, including all of the Azure AD parts... I've tried to clean up the AKV docs which were mixing concepts related to AKV and some related to AAD.

The result is less like a straightforward "do 1, 2, 3 and you're done", but it offers better security (using az ad sp create-for-rbac as was recommended before creates a SP that has access to manage EVERY resource in the Azure subscription - and that's even useless for Dapr since we need data plane access) and more flexibility because the same SP can be used for multiple Azure components.

Also, cc @cmatskas to keep me accountable and make sure I've documented AAD topics correctly

Thanks for working on this. If you haven't yet you can see the docs contribution guidelines here. Also, where it makes sense it is okay to not go too deep with explaining Azure and just linking to Azure docs

@ItalyPaleAle
Copy link
Contributor Author

I've updated the Azure Blob Storage doc too. PR is complete and ready for your review.

@ItalyPaleAle ItalyPaleAle marked this pull request as ready for review September 10, 2021 19:23
@ItalyPaleAle ItalyPaleAle requested a review from a team as a code owner September 10, 2021 19:23
@orizohar orizohar added this to the 1.4 milestone Sep 10, 2021
…-providers/authenticating-azure.md

Co-authored-by: greenie-msft <56556602+greenie-msft@users.noreply.github.com>
…-providers/authenticating-azure.md

Co-authored-by: greenie-msft <56556602+greenie-msft@users.noreply.github.com>
…tate-stores/setup-azure-blobstorage.md

Co-authored-by: Ori Zohar <orzohar@microsoft.com>
@greenie-msft greenie-msft requested a review from a team as a code owner September 14, 2021 22:10
@orizohar orizohar self-requested a review September 14, 2021 22:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants