> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/data-security-documentation/onboard-and-configure/csp-onboarding/outpost-onboarding/working-with-bringing-your-own-azure-app-byoa-outposts/task-1-meet-the-prerequisites-for-azure-byoa-outposts.md). # Task 1: Meet the prerequisites for Azure BYOA outposts This page lists the prerequisites and permission requirements for deploying an Azure outpost in Bring Your Own App registration (BYOA) mode. Complete the checks below before you start the deployment procedure, whether you use the recommended shell script or the manual Azure portal path. {% hint style="info" %} **Important:** Before you begin, ensure that you have Cortex Cloud console access with the outpost creation entitlement. {% endhint %} ## Step 1. Recognize the identities involved in BYOA outpost deployment The following distinct identities are involved in BYOA deployment. * **App Registration Creator**: The user that initially sets up the app registration and service principal (either by running a script or manually using the Azure portal).\ \ Ensure the identity that runs the setup script or performs the manual Azure portal steps holds the `Application Developer` role (or higher) on the tenant. (either by [running a script](/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/working-with-bringing-your-own-azure-app-byoa-outposts/the-shell-script-for-azure-app-registration.md) or [manually using the Azure portal](/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/working-with-bringing-your-own-azure-app-byoa-outposts/task-2-create-the-app-registration-for-the-azure-byoa-outpost.md#manually-in-the-azure-portal)). * **Terraform Runner Identity**: The Azure identity that deploys the outpost by executing `terraform apply`, and the same identity used for all future outpost upgrades. This can be either a user account (for example, an administrator signed in via `az login`) or a service principal that an authorized user impersonates. In either case, the identity must have the required permissions to create and manage the outpost's Azure resources.\ \ Ensure you have the object ID of the Terraform Runner Identity that executes `terraform apply`. You can retrieve the ID by running this command: `az ad sp show --id --query id -o tsv` {% hint style="info" %} **Tip**: Confusing which permissions are needed by which identity is the most common cause of deployment failure. {% endhint %} ## Step 2. Meet the tooling and account prerequisites Confirm that the tooling and account requirements below are in place before you start any BYOA deployment path. * **Azure CLI**: Version 2.x or later (for the recommended shell script approach), or Azure Portal access (for manual setup) * **Terraform**: Version specified in the outpost bundle * **Cortex Cloud account**: Active account with Azure Outpost entitlement * **Azure subscription**: A dedicated Azure subscription for the outpost. The subscription should not contain other workloads and should be free of other resources. * **Entra ID tenant:** Identify the Entra ID tenant where you want the app registration to live. This is the "home tenant" that hosts (or trusts) the Azure subscriptions Cortex Cloud scans. Do not create the app registration in a separate monitored-workload tenant, because Cortex authenticates from the home tenant into the monitored subscription. ## Step 3. Set permissions by identity The permissions your identities need differ by role and by lifecycle stage. Review the tables below to confirm that the App Registration Creator has the setup-time permissions and that the Terraform Runner Identity has the persistent deploy-and-upgrade permissions. ### App Registration Creator permissions The following permissions are needed only during initial setup. You can revoke the access that these permissions grant after setup. | Role / permission | Scope | Why needed | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | |

Application Developer (primary)

OR

Application Administrator (as required only for adding a service principal as an owner of the app registration)


OR

Global Administrator (sufficient but overprivileged)

| Entra ID tenant |

Create the app registration and service principal.

Add owners

| | Privileged Role Administrator (optional) | Entra ID tenant |

Required only if granting the optional Application.Read.All admin consent for Entra ID app inventory.

The optional Application.Read.All admin consent enables Cortex's Entra ID application inventory feature, which discovers and displays all app registrations and enterprise applications in your Entra ID tenant so you can see which applications have access to your Azure resources and detect over-privileged or unused apps. If you do not need this inventory, skip the Privileged Role Administrator role. The outpost itself deploys and scans normally without it.

| ### Terraform Runner Identity permissions The following permissions are persistent and must remain in place for the life of the outpost. They are relevant during deployment and when upgrading. | Role / permission | Scope | Why needed | | --------------------------------------------------------------------- | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | | Owner of the BYO App Registration | Object-scoped (one AppReg only) | Add and/or remove federated identity credentials (FICs). Granted automatically by the setup script via `--tf-runner-object-id `. | | Contributor (or Owner, which also includes User Access Administrator) | Azure subscription | Provision outpost infrastructure: UAMIs, storage, networking, scanner VMs | | User Access Administrator (or Owner, which also includes Contributor) | Azure subscription | Create role assignments between UAMIs and scanned resources | {% hint style="info" %} **Security note**: BYOA grants the Terraform runner zero tenant-level Microsoft Graph permissions. The runner's ability to write federated identity credentials comes entirely from being an owner of one specific app registration. Object-scoped `Application.ReadWrite.OwnedBy` is implicit via ownership, so no admin consent at tenant scope is required. This is a significant reduction compared to standard outposts, which require `Application.ReadWrite.All` at tenant scope. {% endhint %} ## What's next? If you encounter issues, review the [outpost troubleshooting topic](/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/outpost-troubleshooting.md#bring-your-own-app-byoa-troubleshooting---azure). Proceed to [Task 2: Create the app registration for the Azure BYOA outpost](/cortex-cloud-runtime-security/onboard-and-configure/deployment-steps-and-checklist/cloud-service-provider-csp-onboarding/outpost-onboarding/working-with-bringing-your-own-azure-app-byoa-outposts/task-2-create-the-app-registration-for-the-azure-byoa-outpost.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/data-security-documentation/onboard-and-configure/csp-onboarding/outpost-onboarding/working-with-bringing-your-own-azure-app-byoa-outposts/task-1-meet-the-prerequisites-for-azure-byoa-outposts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.