Azure Developer Auth Server (azd auth server) #3979

jongio · 2024-06-04T20:42:48Z

Overview and Problem Statement

This PR introduces the Azure Developer Auth Server (azd auth server start and azd auth server stop), a local identity server designed to facilitate authentication for development scenarios. This server uses the identity authenticated with azd to generate tokens, allowing developers to:

Local Development Authentication: Use tokens from their authenticated azd identity to authenticate in their application code, avoiding the need for other developer credentials. This server provides local emulation to support the credential types in Azure Identity libraries (e.g., ManagedIdentityCredential, DefaultAzureCredential).
Containerized Development: Enable seamless authentication within Docker containers. Authentication using DefaultAzureCredential within containers became challenging after the transition to MSAL. The Azure Developer Auth Server helps resolve this by providing tokens for containerized applications. More details on the issue are available here.
Terraform Integration: Authenticate Terraform using tokens from the Azure Developer Auth Server without relying on the Azure CLI. This simplifies the authentication process for local and container-based development. Refer to the Terraform MSI Guide for more information.

Solution

Azure Developer Auth Server: This command starts a local identity server that provides tokens based on the current azd authenticated identity. The server offers a local emulation for the credential types in Azure Identity libraries, suitable for various development scenarios:

Server Initialization:
- Run azd auth server start to start a server on 127.0.0.1 (localhost) or host.docker.internal for Docker environments.
- Run azd auth server stop to stop the server.
Endpoint Configuration:
- Applications using Azure Identity libraries will interact with this server. Set MSI_ENDPOINT to http://localhost:53028/MSI/token for local development or http://host.docker.internal:53028/MSI/token for container development to facilitate this interaction.
Application Integration:
- Applications configured to use Azure Identity libraries (e.g., ManagedIdentityCredential, DefaultAzureCredential) will obtain tokens from the MSI_ENDPOINT provided by azd auth server start. The server provides these tokens based on the azd authenticated identity, allowing the application to authenticate as if using actual Azure services.

Additional Enhancements:

Alternate Endpoint: Introduce AZD_AUTH_ENDPOINT, an environment variable that can be used as an alternative authentication endpoint for AzureDeveloperCLICredential.
Localhost Restriction: Limit the serving endpoint to 127.0.0.1 to ensure it is only accessible locally.
Secret Validation: Implement a secret generation mechanism at server startup to validate incoming authentication requests, similar to OAuth CSRF, enhancing security.

Open Issues

Security:
- Determine effective ways to secure the server and prevent misuse. Possible solutions include:
  - Restricting access to 127.0.0.1 or host.docker.internal.
  - Using bearer tokens or CSRF-style verification.
- Develop and review a threat model for the Azure Developer Auth Server.
Credential Handling:
- Avoid potential confusion where developers might think they are using actual managed identities when they are using tokens from the Azure Developer Auth Server.
- Manage additional attributes on the Azure Identity objects such as resourceId and TokenCredentialOptions.
User-Assigned Managed Identities:
- Develop a solution for scenarios where users specify a clientId for user-assigned managed identities while using azd auth server start.

Next Steps

Review with the Security Team:
- Conduct a review with the security team to identify any concerns or issues with the approach and ensure alignment with existing systems.

Prioritized List of Security Considerations for `azd auth serve`

Executive Summary

This document provides a security analysis of the azd auth serve implementation, identifying potential threats and recommending mitigation strategies to ensure robust security.

Detailed Analysis

HTTPS for Secure Communication
- Consideration: Serving access tokens over HTTP can lead to interception and misuse.
- Detail: HTTP traffic is unencrypted, making it vulnerable to eavesdropping and man-in-the-middle (MITM) attacks. An attacker on the same network can intercept tokens, leading to unauthorized access to resources.
- Question: Should we restrict all traffic to HTTPS?
- Potential Solution: Encrypt all communications between the client and server using HTTPS to ensure data integrity and confidentiality. This includes obtaining and using SSL/TLS certificates.
Token Scope, Audience, and Security Contexts
- Consideration: Tokens should be issued with the correct audience and scoped appropriately to ensure they are only usable by the intended container or entity, and to maintain separate security contexts.
- Detail: Tokens must be scoped for their intended recipient to prevent misuse. Containers are designed to isolate processes and resources from the host. Sharing tokens directly between the host and container can breach this isolation.
- Question: Should we implement the Azure AD On-Behalf-Of (OBO) flow to properly scope tokens for containers and ensure separate security contexts?
- Potential Solution: Implement Azure AD On-Behalf-Of (OBO) flow to ensure tokens are appropriately scoped for containers and issued with the correct audience.
User Consent and Trust Boundaries
- Consideration: Sharing tokens directly with containers breaches trust boundaries and may not align with user consent.
- Detail: Tokens issued for use on the host machine may grant permissions that are inappropriate for use within a container, leading to unauthorized access if the container is compromised.
- Question: Should we use AAD’s consent dialogs to manage permissions and token grants?
- Potential Solution: Use AAD’s consent dialogs to manage permissions and token grants, ensuring that users and administrators have visibility and control over token usage.
Avoiding Custom Authentication Mechanisms
- Consideration: Custom mechanisms can obscure the token granting process and lead to security issues.
- Detail: Custom authentication mechanisms may not have the same security rigor as established protocols like OAuth. They can also complicate management and auditing.
- Question: Should we avoid custom authentication mechanisms and leverage Azure AD for establishing trust?
- Potential Solution: Leverage Azure AD for establishing trust and managing authentication. This ensures consistency, security, and alignment with Azure AD’s consent model.
Implementing Short-Lived Tokens
- Consideration: Tokens should have a limited lifespan to reduce the risk of misuse if intercepted.
- Detail: Long-lived tokens increase the risk window for potential misuse. Short-lived tokens minimize the impact of token interception.
- Question: Should we issue tokens with short expiration times?
- Potential Solution: Issue tokens with short expiration times, such as 15 minutes, to reduce the risk of misuse if tokens are intercepted.
IP and DNS Spoofing
- Consideration: Ensuring requests come from expected interfaces to prevent spoofing.
- Detail: IP and DNS spoofing can allow attackers to impersonate legitimate clients or servers, leading to unauthorized access.
- Question: Should we verify that requests come from expected interfaces and use mutual TLS authentication?
- Potential Solution: Verify that requests originate from expected interfaces and use mutual TLS authentication to authenticate both the client and server.
Rate Limiting and Abuse Prevention
- Consideration: Prevent excessive requests and potential abuse.
- Detail: Without rate limiting, a service can be overwhelmed by excessive requests, leading to denial of service (DoS) attacks or abuse.
- Question: Should we implement rate limiting to control the number of requests and monitor/log requests?
- Potential Solution: Implement rate limiting to control the number of requests a client can make in a given time period. Monitor and log requests to detect and respond to unusual activity.
Cross-Site Request Forgery (CSRF) Attacks
- Consideration: Protect against CSRF attacks.
- Detail: CSRF attacks can trick users into executing unwanted actions on a web application where they are authenticated.
- Question: Should we implement CSRF tokens and validate them for every request?
- Potential Solution: Implement CSRF tokens and validate them for every request to ensure that requests are legitimate and originated from the intended client.
Secure Storage of Tokens
- Consideration: Ensure tokens are securely stored to prevent unauthorized access.
- Detail: Tokens stored insecurely can be accessed and used by unauthorized parties, leading to security breaches.
- Question: Should we encrypt tokens when stored locally and use secure storage methods?
- Potential Solution: Encrypt tokens when stored locally. Use secure storage methods such as encrypted files or secure storage services to protect tokens from unauthorized access.
Logging and Monitoring
- Consideration: Detect and respond to unauthorized access or misuse.
- Detail: Without proper logging and monitoring, unauthorized access or misuse can go undetected, leading to prolonged security breaches.
- Question: Should we implement centralized logging and monitoring and set up alerts for suspicious activities?
- Potential Solution: Implement centralized logging and monitoring to track access and usage patterns. Set up alerts for suspicious activities to enable prompt detection and response.
Kernel Exploits and Privilege Escalation
- Consideration: Protect against kernel exploits and privilege escalation.
- Detail: Containers share the host OS kernel, making them vulnerable to kernel exploits that can lead to privilege escalation and host compromise.
- Question: Should we regularly update and patch the host OS and kernel, and use container runtime security features?
- Potential Solution: Regularly update and patch the host OS and kernel. Use container runtime security features like Seccomp, AppArmor, or SELinux to restrict container capabilities.
Shared Kernel Vulnerabilities
- Consideration: Containers sharing the same host OS kernel.
- Detail: Containers sharing the same kernel can lead to vulnerabilities if one container is compromised, potentially affecting others.
- Question: Should we use network policies and firewall rules to restrict communication between containers?
- Potential Solution: Use network policies and firewall rules to restrict communication between containers. Implement proper namespace and cgroup configurations to isolate containers.
Host Security
- Consideration: Harden the host OS to prevent unauthorized access.
- Detail: A compromised host OS can undermine the security of all containers running on it.
- Question: Should we disable unnecessary services and secure configuration files on the host OS?
- Potential Solution: Disable unnecessary services, secure configuration files, and regularly audit and update security settings to harden the host OS.
Container Image Vulnerabilities
- Consideration: Ensure container images are secure.
- Detail: Vulnerabilities in container images can be exploited, leading to security breaches.
- Question: Should we use trusted base images, regularly update them, and scan container images for vulnerabilities?
- Potential Solution: Use trusted base images, regularly update them, and scan container images for vulnerabilities before deployment. Ensure that images are obtained from reputable sources.
Access to Docker Socket
- Consideration: Containers with access to the Docker socket can control the Docker daemon.
- Detail: If a container can access the Docker socket, it can potentially control the Docker daemon and compromise the entire host.
- Question: Should we avoid mounting the Docker socket inside containers?
- Potential Solution: Avoid mounting the Docker socket inside containers unless absolutely necessary. Use API gateways or proxy services to control access to the Docker API.
Intra-Container Communication Vulnerabilities
- Consideration: Restrict communication between containers to prevent unauthorized access.
- Detail: Unrestricted communication between containers can lead to security risks if one container is compromised.
- Question: Should we use network policies and firewall rules to limit intra-container communication?
- Potential Solution: Use network policies and firewall rules to limit intra-container communication, ensuring that containers only communicate with necessary services.

Risk Assessment

Security Consideration	Risk Level
HTTPS for Secure Communication	High
Token Scope, Audience, and Security Contexts	High
User Consent and Trust Boundaries	High
Avoiding Custom Authentication Mechanisms	High
Implementing Short-Lived Tokens	Medium
IP and DNS Spoofing	Medium
Rate Limiting and Abuse Prevention	Medium
Cross-Site Request Forgery (CSRF) Attacks	Medium
Secure Storage of Tokens	Medium
Logging and Monitoring	Medium
Kernel Exploits and Privilege Escalation	Low
Shared Kernel Vulnerabilities	Low
Host Security	Low
Container Image Vulnerabilities	Low
Access to Docker Socket	Low
Intra-Container Communication Vulnerabilities	Low

pamelafox · 2024-06-05T05:29:22Z

Very exciting, do you think this will work with MI-as-FIC with MSAL SDK? (What I talked about in the Build talk)

jongio · 2024-06-05T15:46:27Z

Very exciting, do you think this will work with MI-as-FIC with MSAL SDK? (What I talked about in the Build talk)

I don't see why not, but I'm not sure what endpoints that looks for. Do you have more info?

vhvb1989 · 2024-06-05T17:00:00Z

Supporting MI-FIC is way more complicated. It requires an issuer, which is basically a url that is reachable by the application and by EntraId.
In a nutshell, the flow for FIC within an application goes:

application (using MSAL lib) asks the issuer url for a token (certificate)
then it sends the token to EntraId for Authentication. EntraId uses the issuer url to validate the Token is valid (checks signed cert). If valid, EntraId returns a refreshToken.
App gets the refreshToken and can use it to ask EntraId for Authorization tokens (MI) depending on rbac. For example, a token for msgraph
EntraId checks rbac and gives back the bearer token that the app can use to call an Azure Service (if rbac authorized).

When working with MI w/o FIC, azd takes care of 1 and 2. Instead of a trusted issuer, you use the browser to authenticate azd and get a refreshToken.
In MI-FIC world, the app would NOT depend on azd auth login . It would depend on creating a SP with a trusted relation to the issuer url. See: https://learn.microsoft.com/entra/workload-id/workload-identity-federation-create-trust-user-assigned-managed-identity?pivots=identity-wif-mi-methods-azp

ellismg · 2024-06-05T17:17:58Z

IIRC, there are a few flavors of MSI that allow passing a bearer token (also provided in an environment variable) that the personal calling the endpoint has to pass the token. This prevents other processes on the machine from fetching a token unless they have this shared secret.

Do we think we'd want to do that here as well? I'm wondering if the extra handshake would be useful from a security perspective.

pamelafox · 2024-06-05T17:19:34Z

Victor just said lots of great things that I only barely understand, but in case it's helpful, here's the PR that adds support for MI-as-FIC to MSAL SDKs: AzureAD/microsoft-authentication-library-for-python#480

ellismg

Direction looks good to me (but I'll admit I've been on the "we should be leveraging MSI in some way like this" plan for a long time).

It's possible we'll want to use of one of the MSI flavors that allows passing a bearer token to prevent any process on the machine from fetching a token as the current user, but I get that we are in a bit of a hard place here because we are trying to emulate one of the existing MSI protocols instead of getting to design our own so we have limited degrees of flexibility.

ellismg · 2024-06-05T17:21:00Z

cli/azd/cmd/auth_serve.go

+	}
+}
+
+func (serve *serveAction) start(port string) {


NIT: It would be better if this was an int not a string perhaps? If we pass in a non int I assume ListenAndServe() is going to return an error.

ellismg · 2024-06-05T17:21:51Z

cli/azd/cmd/auth_serve.go

+		resource = "https://management.azure.com/"
+	}
+
+	fmt.Printf("Received request for resource: %s\n", resource)


Let's use log here instead of writing directly to the console.

ellismg · 2024-06-05T17:25:25Z

cli/azd/cmd/auth_serve.go

+		TenantID: "",
+	})
+	if err != nil {
+		fmt.Printf("credentialProvider: %v", err)


For these error cases, we likely still want to call something like http.Error instead of just returning here which I think would just close the connection without an HTTP response at all. Using log would also be preferable vs pushing to the console.

In addition - if the user is never able to provide a tenant ID, perhaps we call the credentialProvider when we construct the serve action and save it on the object, so we don't have to do it per request?

ellismg · 2024-06-05T17:26:57Z

cli/azd/cmd/auth_serve.go

+
+// tokenHandler handles token requests.
+func (serve *serveAction) tokenHandler(w http.ResponseWriter, r *http.Request) {
+	resource := r.URL.Query().Get("resource")


Do we need to ensure anything about the verb that was used (I thought that MSI uses POST, not GET, for some reason?)

https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http
it uses get

We should ensure that the Metadata header is present, as outlined on the linked page and reject other verbs, then.

ellismg · 2024-06-05T17:27:20Z

cli/azd/cmd/auth_serve.go

+}
+
+func (serve *serveAction) Run(ctx context.Context) (*actions.ActionResult, error) {
+	port := os.Getenv("AZD_AUTH_SERVER_PORT")


Why not add a --port to the command instead of controlling this via an env-var?

mattgotteiner · 2024-06-05T20:59:27Z

this is awesome. Great work!

jongio · 2024-06-10T14:41:36Z

Hey @ellismg @wbreza @vhvb1989

I wanted to get your feedback on an alternate approach to enhance azd auth serve. This involves introducing a new environment variable, AZD_AUTH_ENDPOINT, to allow AzureDeveloperCLICredential to utilize an alternative authentication endpoint if specified.

Reasoning Behind This Approach:

Avoiding Confusion with ManagedIdentityCredential:

Clarity: This approach ensures that we do not "trick" ManagedIdentityCredential. By keeping authentication mechanisms distinct, we avoid situations where users might mistakenly believe they are using ManagedIdentity when they are not. Such confusion could lead to unintended side effects or security concerns, especially if users rely on different authentication behaviors or permissions.

Proposed Changes:

New Endpoint: AZD_AUTH_ENDPOINT
- Introduce AZD_AUTH_ENDPOINT as an environment variable that AzureDeveloperCLICredential will check for.
- If set, use this endpoint for authentication, providing an alternative to the default process.
Localhost Restriction:
- Restrict the serving endpoint to 127.0.0.1 to ensure it is only accessible locally, reducing exposure to external requests.
Secret Validation Mechanism:
- Generate a unique secret value when the server starts, required for validating incoming authentication requests.
- This functions similarly to the OAuth CSRF state parameter, adding an additional security layer to ensure request validity.

Security Considerations:

Localhost Binding: Limits the endpoint to local access, mitigating the risk of external exploits.
Secret Validation: Provides an additional layer of security by validating request authenticity, protecting against request forgery.

References:

OAuth 2.0 CSRF State Parameter

Would appreciate your thoughts on this approach and any potential implications or improvements you foresee.

Thanks for your input!

Jon

ellismg · 2024-06-10T17:31:58Z

@jongio What you've outlined above is very close to the external auth protocol that we designed for delegating auth to both VS and VS Code: https://github.com/Azure/azure-dev/blob/main/cli/azd/docs/external-authentication.md. This was designed around the TokenRequestContext type from the Track 2 Azure SDKs instead of building off MSAL's wire format (and hence we talk in terms of scopes and not resources)

I feel like the original approach of creating a local MSI endpoint would give us larger reach (since I suspect in practice most credential chains include ManagedIdentityCredential while not all will include AzureDeveloperCLICredential, perhaps because they are on "track 1" or an older track 2 DAC that didn't contain this). For example, if we landed something like the MSI thing, we could use it to have terraform auth'd correctly when being run by azd (by us launching this server and then setting some TF specific vars) but they don't support Azure Developer CLI Credential, so this new strategy would not work here.

I do believe there are flavors of MSI (perhaps the one that functions speaks) that allows a shared secret so that would give us some security improvements while still speaking MSI like stuff. I don't have an opinion on if "faking" MSI in this way is good or bad. My general belief is that it is "fine", especially in cases like the above where the user takes explicit action to launch the server - because they are aware of what is going on and if their app behaves strangely, they will have an understanding that it's running in a non standard environment and can diagnose.

I do think that some form of common HTTP based protocol that allows us to separate the system requesting the token from the system providing the token is a good design - it's much better than the existing strategy of a credential per tool type.

If we do end up creating our own wire protocol, we may also want to include the ability for it to run over HTTPS with a self signed certificate (which can be presented along with the bearer token for the HTTPS protocol via an env-var to the client). We added this level of security based on feedback from an internal design review with the security team for our HTTP JSON-RPC based integration point with VS.

jongio · 2024-06-24T16:46:50Z

@jongio What you've outlined above is very close to the external auth protocol that we designed for delegating auth to both VS and VS Code: https://github.com/Azure/azure-dev/blob/main/cli/azd/docs/external-authentication.md. This was designed around the TokenRequestContext type from the Track 2 Azure SDKs instead of building off MSAL's wire format (and hence we talk in terms of scopes and not resources)

I feel like the original approach of creating a local MSI endpoint would give us larger reach (since I suspect in practice most credential chains include ManagedIdentityCredential while not all will include AzureDeveloperCLICredential, perhaps because they are on "track 1" or an older track 2 DAC that didn't contain this). For example, if we landed something like the MSI thing, we could use it to have terraform auth'd correctly when being run by azd (by us launching this server and then setting some TF specific vars) but they don't support Azure Developer CLI Credential, so this new strategy would not work here.

I do believe there are flavors of MSI (perhaps the one that functions speaks) that allows a shared secret so that would give us some security improvements while still speaking MSI like stuff. I don't have an opinion on if "faking" MSI in this way is good or bad. My general belief is that it is "fine", especially in cases like the above where the user takes explicit action to launch the server - because they are aware of what is going on and if their app behaves strangely, they will have an understanding that it's running in a non standard environment and can diagnose.

I do think that some form of common HTTP based protocol that allows us to separate the system requesting the token from the system providing the token is a good design - it's much better than the existing strategy of a credential per tool type.

If we do end up creating our own wire protocol, we may also want to include the ability for it to run over HTTPS with a self signed certificate (which can be presented along with the bearer token for the HTTPS protocol via an env-var to the client). We added this level of security based on feedback from an internal design review with the security team for our HTTP JSON-RPC based integration point with VS.

I have updated the PR description above to reflect this and other discussions. We'll leave this as an optional enhancement.

azure-sdk · 2024-06-27T21:06:55Z

Azure Dev CLI Install Instructions

Install scripts

MacOS/Linux

May elevate using sudo on some platforms and configurations

bash:

curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979/uninstall-azd.sh | bash;
curl -fsSL https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979/install-azd.sh | bash -s -- --base-url https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979 --version '' --verbose --skip-verify

pwsh:

Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979/uninstall-azd.ps1' -OutFile uninstall-azd.ps1; ./uninstall-azd.ps1
Invoke-RestMethod 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979/install-azd.ps1' -OutFile install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979' -Version '' -SkipVerify -Verbose

Windows

PowerShell install

powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979/uninstall-azd.ps1' > uninstall-azd.ps1; ./uninstall-azd.ps1;"
powershell -c "Set-ExecutionPolicy Bypass Process; irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979/install-azd.ps1' > install-azd.ps1; ./install-azd.ps1 -BaseUrl 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979' -Version '' -SkipVerify -Verbose;"

MSI install

powershell -c "irm 'https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979/azd-windows-amd64.msi' -OutFile azd-windows-amd64.msi; msiexec /i azd-windows-amd64.msi /qn"

Standalone Binary

MSI

x86_64 - https://azuresdkreleasepreview.blob.core.windows.net/azd/standalone/pr/3979/azd-windows-amd64.msi

Documentation

learn.microsoft.com documentation

title: Azure Developer CLI reference
description: This article explains the syntax and parameters for the various Azure Developer CLI commands.
author: alexwolfmsft
ms.author: alexwolf
ms.date: 06/27/2024
ms.service: azure-dev-cli
ms.topic: conceptual
ms.custom: devx-track-azdevcli

Azure Developer CLI reference

This article explains the syntax and parameters for the various Azure Developer CLI commands.

azd

The Azure Developer CLI (azd) is an open-source tool that helps onboard and manage your application on Azure

Options

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --docs         Opens the documentation for azd in your web browser.
  -h, --help         Gets help for azd.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd auth

Authenticate with Azure.

Options

      --docs   Opens the documentation for azd auth in your web browser.
  -h, --help   Gets help for auth.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd auth login

Log in to Azure.

Synopsis

Log in to Azure.

When run without any arguments, log in interactively using a browser. To log in using a device code, pass
--use-device-code.

To log in as a service principal, pass --client-id and --tenant-id as well as one of: --client-secret,
--client-certificate, or --federated-credential-provider.

To log in using a managed identity, pass --managed-identity, which will use the system assigned managed identity.
To use a user assigned managed identity, pass --client-id in addition to --managed-identity with the client id of
the user assigned managed identity you wish to use.

azd auth login [flags]

Options

      --check-status                           Checks the log-in status instead of logging in.
      --client-certificate string              The path to the client certificate for the service principal to authenticate with.
      --client-id string                       The client id for the service principal to authenticate with.
      --client-secret string                   The client secret for the service principal to authenticate with. Set to the empty string to read the value from the console.
      --docs                                   Opens the documentation for azd auth login in your web browser.
      --federated-credential-provider string   The provider to use to acquire a federated token to authenticate with.
  -h, --help                                   Gets help for login.
      --managed-identity                       Use a managed identity to authenticate.
      --redirect-port int                      Choose the port to be used as part of the redirect URI during interactive login.
      --tenant-id string                       The tenant id or domain name to authenticate with.
      --use-device-code[=true]                 When true, log in by using a device code instead of a browser.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd auth logout

Log out of Azure.

Synopsis

Log out of Azure

azd auth logout [flags]

Options

      --docs   Opens the documentation for azd auth logout in your web browser.
  -h, --help   Gets help for logout.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd auth serve

Starts a local Managed Identity endpoint for development purposes.

azd auth serve [flags]

Options

      --docs   Opens the documentation for azd auth serve in your web browser.
  -h, --help   Gets help for serve.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd config

Manage azd configurations (ex: default Azure subscription, location).

Synopsis

Manage the Azure Developer CLI user configuration, which includes your default Azure subscription and location.

Available since azure-dev-cli_0.4.0-beta.1.

The easiest way to configure azd for the first time is to run azd init. The subscription and location you select will be stored in the config.json file located in the config directory. To configure azd anytime afterwards, you'll use azd config set.

The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.

Options

      --docs   Opens the documentation for azd config in your web browser.
  -h, --help   Gets help for config.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd config get

Gets a configuration.

Synopsis

Gets a configuration in the configuration path.

The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.

azd config get <path> [flags]

Options

      --docs   Opens the documentation for azd config get in your web browser.
  -h, --help   Gets help for get.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd config list-alpha

Display the list of available features in alpha stage.

azd config list-alpha [flags]

Options

      --docs   Opens the documentation for azd config list-alpha in your web browser.
  -h, --help   Gets help for list-alpha.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd config reset

Resets configuration to default.

Synopsis

Resets all configuration in the configuration path.

The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable to the default.

azd config reset [flags]

Options

      --docs    Opens the documentation for azd config reset in your web browser.
  -f, --force   Force reset without confirmation.
  -h, --help    Gets help for reset.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd config set

Sets a configuration.

Synopsis

Sets a configuration in the configuration path.

The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.

azd config set <path> <value> [flags]

Examples

azd config set defaults.subscription <yourSubscriptionID>
azd config set defaults.location eastus

Options

      --docs   Opens the documentation for azd config set in your web browser.
  -h, --help   Gets help for set.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd config show

Show all the configuration values.

Synopsis

Show all configuration values in the configuration path.

The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.

azd config show [flags]

Options

      --docs   Opens the documentation for azd config show in your web browser.
  -h, --help   Gets help for show.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd config unset

Unsets a configuration.

Synopsis

Removes a configuration in the configuration path.

The default value of the config directory is:

$HOME/.azd on Linux and macOS
%USERPROFILE%\.azd on Windows

The configuration directory can be overridden by specifying a path in the AZD_CONFIG_DIR environment variable.

azd config unset <path> [flags]

Examples

azd config unset defaults.location

Options

      --docs   Opens the documentation for azd config unset in your web browser.
  -h, --help   Gets help for unset.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd deploy

Deploy the application's code to Azure.

azd deploy <service> [flags]

Options

      --all                   Deploys all services that are listed in azure.yaml
      --docs                  Opens the documentation for azd deploy in your web browser.
  -e, --environment string    The name of the environment to use.
      --from-package string   Deploys the application from an existing package.
  -h, --help                  Gets help for deploy.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd down

Delete Azure resources for an application.

azd down [flags]

Options

      --docs                 Opens the documentation for azd down in your web browser.
  -e, --environment string   The name of the environment to use.
      --force                Does not require confirmation before it deletes resources.
  -h, --help                 Gets help for down.
      --purge                Does not require confirmation before it permanently deletes resources that are soft-deleted by default (for example, key vaults).

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd env

Manage environments.

Options

      --docs   Opens the documentation for azd env in your web browser.
  -h, --help   Gets help for env.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd env get-values

Get all environment values.

azd env get-values [flags]

Options

      --docs                 Opens the documentation for azd env get-values in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for get-values.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd env list

List environments.

azd env list [flags]

Options

      --docs   Opens the documentation for azd env list in your web browser.
  -h, --help   Gets help for list.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd env new

Create a new environment and set it as the default.

azd env new <environment> [flags]

Options

      --docs                  Opens the documentation for azd env new in your web browser.
  -h, --help                  Gets help for new.
  -l, --location string       Azure location for the new environment
      --subscription string   Name or ID of an Azure subscription to use for the new environment

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd env refresh

Refresh environment settings by using information from a previous infrastructure provision.

azd env refresh <environment> [flags]

Options

      --docs                 Opens the documentation for azd env refresh in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for refresh.
      --hint string          Hint to help identify the environment to refresh

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd env select

Set the default environment.

azd env select <environment> [flags]

Options

      --docs   Opens the documentation for azd env select in your web browser.
  -h, --help   Gets help for select.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd env set

Manage your environment settings.

azd env set <key> <value> [flags]

Options

      --docs                 Opens the documentation for azd env set in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for set.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd hooks

Develop, test and run hooks for an application. (Beta)

Options

      --docs   Opens the documentation for azd hooks in your web browser.
  -h, --help   Gets help for hooks.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd hooks run

Runs the specified hook for the project and services

azd hooks run <name> [flags]

Options

      --docs                 Opens the documentation for azd hooks run in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for run.
      --platform string      Forces hooks to run for the specified platform.
      --service string       Only runs hooks for the specified service.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd init

Initialize a new application.

azd init [flags]

Options

  -b, --branch string         The template branch to initialize from. Must be used with a template argument (--template or -t).
      --docs                  Opens the documentation for azd init in your web browser.
  -e, --environment string    The name of the environment to use.
  -f, --filter strings        The tag(s) used to filter template results. Supports comma-separated values.
      --from-code             Initializes a new application from your existing code.
  -h, --help                  Gets help for init.
  -l, --location string       Azure location for the new environment
  -s, --subscription string   Name or ID of an Azure subscription to use for the new environment
  -t, --template string       Initializes a new application from a template. You can use Full URI, <owner>/<repository>, or <repository> if it's part of the azure-samples organization.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd monitor

Monitor a deployed application. (Beta)

azd monitor [flags]

Options

      --docs                 Opens the documentation for azd monitor in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for monitor.
      --live                 Open a browser to Application Insights Live Metrics. Live Metrics is currently not supported for Python apps.
      --logs                 Open a browser to Application Insights Logs.
      --overview             Open a browser to Application Insights Overview Dashboard.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd package

Packages the application's code to be deployed to Azure. (Beta)

azd package <service> [flags]

Options

      --all                  Packages all services that are listed in azure.yaml
      --docs                 Opens the documentation for azd package in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for package.
      --output-path string   File or folder path where the generated packages will be saved.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd pipeline

Manage and configure your deployment pipelines. (Beta)

Options

      --docs   Opens the documentation for azd pipeline in your web browser.
  -h, --help   Gets help for pipeline.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd pipeline config

Configure your deployment pipeline to connect securely to Azure. (Beta)

azd pipeline config [flags]

Options

      --auth-type string             The authentication type used between the pipeline provider and Azure for deployment (Only valid for GitHub provider). Valid values: federated, client-credentials.
      --docs                         Opens the documentation for azd pipeline config in your web browser.
  -e, --environment string           The name of the environment to use.
  -h, --help                         Gets help for config.
      --principal-id string          The client id of the service principal to use to grant access to Azure resources as part of the pipeline.
      --principal-name string        The name of the service principal to use to grant access to Azure resources as part of the pipeline.
      --principal-role stringArray   The roles to assign to the service principal. By default the service principal will be granted the Contributor and User Access Administrator roles. (default [Contributor,User Access Administrator])
      --provider string              The pipeline provider to use (github for Github Actions and azdo for Azure Pipelines).
      --remote-name string           The name of the git remote to configure the pipeline to run on. (default "origin")

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd provision

Provision the Azure resources for an application.

azd provision [flags]

Options

      --docs                 Opens the documentation for azd provision in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for provision.
      --no-state             Do not use latest Deployment State (bicep only).
      --preview              Preview changes to Azure resources.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd restore

Restores the application's dependencies. (Beta)

azd restore <service> [flags]

Options

      --all                  Restores all services that are listed in azure.yaml
      --docs                 Opens the documentation for azd restore in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for restore.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd show

Display information about your app and its resources.

azd show [flags]

Options

      --docs                 Opens the documentation for azd show in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for show.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd template

Find and view template details. (Beta)

Options

      --docs   Opens the documentation for azd template in your web browser.
  -h, --help   Gets help for template.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd template list

Show list of sample azd templates. (Beta)

azd template list [flags]

Options

      --docs             Opens the documentation for azd template list in your web browser.
  -f, --filter strings   The tag(s) used to filter template results. Supports comma-separated values.
  -h, --help             Gets help for list.
  -s, --source string    Filters templates by source.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd template show

Show details for a given template. (Beta)

azd template show <template> [flags]

Options

      --docs   Opens the documentation for azd template show in your web browser.
  -h, --help   Gets help for show.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd template source

View and manage template sources. (Beta)

Options

      --docs   Opens the documentation for azd template source in your web browser.
  -h, --help   Gets help for source.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd template source add

Adds an azd template source at the specified key (Beta)

azd template source add <key> [flags]

Options

      --docs              Opens the documentation for azd template source add in your web browser.
  -h, --help              Gets help for add.
  -l, --location string   Location of the template source.
  -n, --name string       Display name of the template source.
  -t, --type string       Kind of the template source.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd template source list

Lists the configured azd template sources. (Beta)

azd template source list [flags]

Options

      --docs   Opens the documentation for azd template source list in your web browser.
  -h, --help   Gets help for list.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd template source remove

Removes the specified azd template source (Beta)

azd template source remove <key> [flags]

Options

      --docs   Opens the documentation for azd template source remove in your web browser.
  -h, --help   Gets help for remove.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd up

Provision Azure resources, and deploy your project with a single command.

azd up [flags]

Options

      --docs                 Opens the documentation for azd up in your web browser.
  -e, --environment string   The name of the environment to use.
  -h, --help                 Gets help for up.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

azd version

Print the version number of Azure Developer CLI.

azd version [flags]

Options

      --docs   Opens the documentation for azd version in your web browser.
  -h, --help   Gets help for version.

Options inherited from parent commands

  -C, --cwd string   Sets the current working directory.
      --debug        Enables debugging and diagnostics logging.
      --no-prompt    Accepts the default value instead of prompting, or it fails if there is no default.

Azure Developer Auth Server (azd auth server) #3979

Are you sure you want to change the base?

Azure Developer Auth Server (azd auth server) #3979

Conversation

jongio commented Jun 4, 2024 • edited Loading

Overview and Problem Statement

Solution

Open Issues

Next Steps

Prioritized List of Security Considerations for azd auth serve

Executive Summary

Detailed Analysis

Risk Assessment

pamelafox commented Jun 5, 2024

jongio commented Jun 5, 2024

vhvb1989 commented Jun 5, 2024 • edited Loading

ellismg commented Jun 5, 2024

pamelafox commented Jun 5, 2024

ellismg left a comment

Choose a reason for hiding this comment

ellismg Jun 5, 2024

Choose a reason for hiding this comment

ellismg Jun 5, 2024

Choose a reason for hiding this comment

ellismg Jun 5, 2024

Choose a reason for hiding this comment

ellismg Jun 5, 2024

Choose a reason for hiding this comment

mattgotteiner Jun 5, 2024

Choose a reason for hiding this comment

ellismg Jun 6, 2024

Choose a reason for hiding this comment

ellismg Jun 5, 2024

Choose a reason for hiding this comment

mattgotteiner commented Jun 5, 2024

jongio commented Jun 10, 2024

Reasoning Behind This Approach:

Proposed Changes:

Security Considerations:

References:

ellismg commented Jun 10, 2024

jongio commented Jun 24, 2024

azure-sdk commented Jun 27, 2024

Azure Dev CLI Install Instructions

Install scripts

MacOS/Linux

Windows

Standalone Binary

MSI

Documentation

title: Azure Developer CLI reference description: This article explains the syntax and parameters for the various Azure Developer CLI commands. author: alexwolfmsft ms.author: alexwolf ms.date: 06/27/2024 ms.service: azure-dev-cli ms.topic: conceptual ms.custom: devx-track-azdevcli

Azure Developer CLI reference

azd

Options

See also

azd auth

Options

Options inherited from parent commands

See also

azd auth login

Synopsis

Options

Options inherited from parent commands

See also

azd auth logout

Synopsis

Options

Options inherited from parent commands

See also

azd auth serve

Options

Options inherited from parent commands

See also

azd config

Synopsis

Options

Options inherited from parent commands

See also

azd config get

Synopsis

jongio commented Jun 4, 2024 •

edited

Loading

Prioritized List of Security Considerations for `azd auth serve`

vhvb1989 commented Jun 5, 2024 •

edited

Loading

title: Azure Developer CLI reference
description: This article explains the syntax and parameters for the various Azure Developer CLI commands.
author: alexwolfmsft
ms.author: alexwolf
ms.date: 06/27/2024
ms.service: azure-dev-cli
ms.topic: conceptual
ms.custom: devx-track-azdevcli