# Setting up Aembit in a VMware vSphere environment

> How to deploy and configure Aembit in a VMware vSphere environment

This page describes how to set up Network Identity Attestor in a VMware vSphere environment for Aembit Edge. NIA provides cryptographically verifiable identity for workloads running in virtualized environments by issuing attestation documents based on VM metadata.

In this guide you’ll deploy and configure the following Aembit Edge Components in your vSphere environment:

1. [Agent Controller](#configure-and-install-agent-controller)
2. [Network Identity Attestor](#install-and-configure-network-identity-attestor)
3. [Agent Proxy](#install-and-configure-agent-proxy)

After setting up these components, you’ll configure an Access Policy in your Aembit Tenant to use NIA for workload identity attestation. Your Access Policy consists of the following components:

1. [Client Workload](#client-workload)
2. [Trust Provider](#trust-provider)
3. [Credential Provider](#credential-provider) that issues JWT SVID tokens to the VMware-based Client Workload from [Azure Entra ID](#configure-federated-credentials-in-azure)
4. [Server Workload](#server-workload)

Then, you’ll [test the end-to-end setup](#test-the-end-to-end-flow) by running a Client Workload VM that authenticates to Azure Entra ID using the NIA-based attestation.

> **If you run into trouble…**
>
> See the [Troubleshooting section](#troubleshooting) at the end of this guide for common issues and solutions.

## Prerequisites

* Aembit Tenant with read/write permissions for Agent Controllers, Access Policies, and their components.

* Aembit Edge Component binaries for:

  * Agent Controller `1.27.2890`
  * Agent Proxy `1.27.3865`
  * Network Identity Attestor `1.27.141`

* An existing vSphere cluster with:

  * vCenter `8.0.3.0+`

  * ESXi `8.0 U2+ (VM v21)`

  * Deploy each component as a separate VM within the same VMware cluster:

    * Agent Controller - See [Supported operating systems for VMs](/reference/support-matrix#supported-operating-systems-for-vms)
    * Agent Proxy - See [Supported operating systems for VMs](/reference/support-matrix#supported-operating-systems-for-vms)
    * Network Identity Attestor (Ubuntu 24.04 or later)

## Configure and install Agent Controller

### Create an Agent Controller in Aembit Cloud

Before installing the Agent Controller binary in your runtime environment, create an Agent Controller in your Aembit Tenant and generate a Device Code for registration.

> **Device Code authentication**
>
> In VMware environments without cloud metadata services (AWS, Azure, GCP), Agent Controller uses Device Code authentication to register with Aembit Cloud. Device Codes are temporary one-time-use codes valid for 15 minutes.
>
> For more information, see [About the Aembit Agent Controller](/user-guide/deploy-install/about-agent-controller).

> **Default Resource Set**
>
> You must be in the `Default` Resource Set to create an Agent Controller. If you are in a different Resource Set, switch to the `Default` Resource Set before proceeding.

To create an Agent Controller, follow these steps:

1. Log in to your Aembit Tenant: `https://<tenantId>.aembit.io`
2. Go to **Edge Components -> Agent Controllers**.
3. Click **+ New**.
4. Enter a **Name** and optional **Description**.
5. Leave **Trust Provider** unselected (Device Code authentication doesn’t require a Trust Provider).
6. Optionally (but recommended), for **Allowed TLS Hostname**, enter the hostname or FQDN of the Agent Controller VM. Example: `<AGENT_CONTROLLER_VM_HOSTNAME>.example.local`
7. Click **Save**.
8. Click **Generate Code** to create a Device Code.
9. Copy the install command displayed in the UI, or note the Device Code for manual installation.

> **Tip**
>
> To reduce errors, copy the install command directly from the Aembit Web UI. The UI populates your tenant ID and Device Code automatically.

### Install Agent Controller binary on a VM

To install the Agent Controller binary, follow these steps:

1. Connect to the VM where you want to install Agent Controller.

2. Use SSH to connect to the VM:

   ```shell
   ssh -i "<path/to/your/ssh/key>" <your-username-or-remote-host>@<hostname>
   ```

3. Download the latest Agent Controller release, making sure to replace `<version_number>` with the Agent Controller version you’d like to use:

   ```shell
   curl -O "https://releases.aembit.io/agent_controller/<version_number>/linux/amd64/aembit_agent_controller_linux_amd64_<version_number>.tar.gz"
   ```

4. Unpack the archive:

   ```shell
   tar xf aembit_agent_controller_linux_amd64.<version_number>.tar.gz
   ```

5. Go to the unpacked directory:

   ```shell
   cd aembit_agent_controller_linux_amd64
   ```

6. Run the installer using the Device Code from the previous step. Replace `<TenantID>` and `<DeviceCode>` with the values from your Aembit Tenant, and `</path/to/tls.crt>` and `</path/to/tls.key>` with the paths to your TLS certificate and key files:

   ```shell
   sudo TLS_PEM_PATH=</path/to/tls.crt> TLS_KEY_PATH=</path/to/tls.key> AEMBIT_TENANT_ID=<TenantID> AEMBIT_DEVICE_CODE=<DeviceCode> ./install
   ```

   > **Device Code expiration**
   >
   > Device Codes expire after 15 minutes. If your Device Code expires before installation completes, generate a new one from the Aembit Cloud UI.

7. Verify the installation by running the following command:

   ```plaintext
   ps aux | grep aembit
   ```

You’ll see output similar to the following if you’ve successfully installed Agent Controller:

```shell
ps aux | grep aembit
aembit_+    4580  0.2 21.1 273740284 205436 ?    Ssl  Dec10  45:54 /opt/aembit/edge/agent_controller/<version_number>/bin/aembit_agent_controller
root        4581  0.0  0.7  34912  7684 ?        Ss   Dec10   0:00 /usr/lib/systemd/systemd-journald aembit_agent_controller
```

### Verify Agent Controller installation

After creating your VM and installing the Agent Controller binary, you can verify that Aembit Cloud has registered the VM as a new Agent Controller.

To verify the registration of your new Agent Controller, follow the steps:

1. Log in to your Aembit Tenant.
2. Go to **Reporting -> Audit Logs**.
3. In the list, look in the **Activity** column for `registered agent controller` with the name of your VM as the **Target**.
4. Click to expand the entry and inspect the left column, you should see that the Result has a value of Success similar to the following screenshot:

> **HTTP proxy configuration**
>
> If your network routes outbound traffic through an HTTP proxy, configure the `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables for Agent Controller. See [Agent Controller environment variables](/reference/edge-components/edge-component-env-vars#http_proxy) for details.

### Prepare TLS certificates for NIA

Before installing Network Identity Attestor, obtain TLS certificates for secure communication. Use [custom TLS certificates](/user-guide/deploy-install/advanced-options/agent-controller/configure-customer-pki-agent-controller-tls/).

> **Customer-managed TLS required**
>
> Network Identity Attestor doesn’t support Aembit Managed TLS. You must use customer-managed TLS certificates for all components in this setup:
>
> * Agent Controller
> * Network Identity Attestor
> * Agent Proxy (for communication with NIA)
>
> For details, see [Configure a custom PKI-based Agent Controller TLS](/user-guide/deploy-install/advanced-options/agent-controller/configure-customer-pki-agent-controller-tls/).

> **Use your internal PKI for production**
>
> For production environments, obtain certificates from your organization’s internal Public Key Infrastructure (PKI) or a trusted Certificate Authority. The following examples show how to generate a Certificate Signing Request (CSR) to submit to your internal CA.

To prepare TLS certificates, follow these steps:

1. Generate a private key and CSR for the TLS certificate:

   ```shell
   openssl genrsa -out tls.key 2048
   openssl req -new -key tls.key -out tls.csr \
     -subj "/CN=<NIA_HOSTNAME>" \
     -addext "subjectAltName=DNS:<NIA_HOSTNAME>"
   ```

2. Submit `tls.csr` to your internal CA and obtain the signed certificate. Save the certificate as `tls.crt`. Include the full certificate chain (leaf certificate first, followed by intermediates).

3. Verify the certificate and key match:

   ```shell
   openssl x509 -noout -modulus -in tls.crt | openssl md5
   openssl rsa -noout -modulus -in tls.key | openssl md5
   ```

   Both commands should output the same MD5 hash.

4. Ensure that the TLS certificate and key files remain accessible to the Network Identity Attestor during installation. You use these files when you set up the Network Identity Attestor.

### Prepare attestation signing certificate

The NIA requires a separate signing certificate to sign attestation documents. This certificate is different from the TLS certificate and has specific requirements.

For attestation signing certificate requirements, see [Certificate requirements](/user-guide/deploy-install/virtual-envs/reference-network-identity-attestation#certificate-requirements).

> **RSA keys required**
>
> The NIA only supports RSA keys for signing certificates in the initial release. ECDSA and Ed25519 aren’t supported.

1. Generate an RSA private key in `PKCS#8` format:

   ```shell
   openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -out signing.key
   ```

2. Generate a CSR with the required extensions for digital signatures:

   ```shell
   openssl req -new -key signing.key -out signing.csr \
     -subj "/CN=NIA Signing Certificate" \
     -addext "keyUsage = critical,digitalSignature" \
     -addext "basicConstraints = critical,CA:FALSE"
   ```

3. Submit `signing.csr` to your internal CA and request a certificate with:

   * **Key Usage**: Digital Signature (critical)
   * **Basic Constraints**: CA:FALSE (must NOT be a CA certificate)

   Save the signed certificate as `signing.crt`.

4. Verify the signing certificate has the correct key usage:

   ```shell
   openssl x509 -in signing.crt -text -noout | grep -A1 "Key Usage"
   ```

   Verify that `Digital Signature` appears in the output.

## Install and configure Network Identity Attestor

### Install the Network Identity Attestor binary

> **Run as root**
>
> You **must** execute the installation script with root user privileges. Otherwise, the installation fails.

1. Connect to the VM where you want to install Network Identity Attestor.

2. Download the Network Identity Attestor release:

   ```shell
   wget https://releases.aembit-eng.com/netid_attestor/1.27.141/linux/amd64/aembit_netid_attestor_linux_amd64_1.27.141.tar.gz
   ```

3. Unpack the archive:

   ```shell
   tar xf aembit_netid_attestor_linux_amd64_1.27.141.tar.gz
   ```

4. Go to the unpacked directory:

   ```shell
   cd aembit_netid_attestor_linux_amd64_1.27.141
   ```

5. Copy the required certificate and key files to the NIA VM:

   * `tls.crt` - TLS certificate chain
   * `tls.key` - TLS private key
   * `signing.crt` - Attestation signing certificate
   * `signing.key` - Attestation signing private key

6. Create a vCenter credentials file. Include the username and password on a single line, separated by a colon:

   ```shell
   touch vcenter_credentials
   chmod 600 vcenter_credentials
   echo "USERNAME@DOMAIN:YOUR_PASSWORD" > vcenter_credentials
   ```

7. Run the installer with the required environment variables:

   ```shell
   sudo TLS_PEM_PATH=$HOME/tls.crt \
     TLS_KEY_PATH=$HOME/tls.key \
     AEMBIT_ATTESTATION_SIGNING_KEY_PATH=$HOME/signing.key \
     AEMBIT_ATTESTATION_SIGNING_CERTIFICATE_PATH=$HOME/signing.crt \
     AEMBIT_VCENTER_CREDENTIALS_FILE=$HOME/vcenter_credentials \
     AEMBIT_VCENTER_URL=https://vcenter.example.com:443 \
     AEMBIT_LOG_LEVEL=debug \
     ./install
   ```

   Expected output:

   ```plaintext
   Info: Installing Aembit NetID Attestor
   Info: Checking for required package dependencies.
   Info: Group "aembit" exists
   Info: User "aembit_netid_attestor" exists
   Info: Copied TLS pem and key.
   ```

8. Verify the service is running:

   ```shell
   sudo systemctl status aembit_netid_attestor
   ```

9. Check the logs to confirm successful startup:

   ```shell
   journalctl --namespace=aembit_netid_attestor -f
   ```

   Look for messages indicating successful vCenter session token acquisition and the listening IP/port.

> **Clean up sensitive files**
>
> After successful installation, delete the original certificate, key, and credentials files from the installation directory. The installer creates secure copies that the NIA service uses at runtime.
>
> ```shell
> rm -f tls.crt tls.key signing.crt signing.key vcenter_credentials
> ```

## Install and configure Agent Proxy

You must install and configure Agent Proxy on a VM in your vSphere environment so it can register with Agent Controller, communicate with Aembit Cloud and Network Identity Attestor, and handle

workload identity issuance and attestation requests.

### Install the Agent Proxy binary

1. Connect to the VM you want to install Agent Proxy.

2. Download the latest Agent Proxy release, making sure to replace `<version_number>` with the Agent Proxy version you’d like to use:

   ```shell
   curl -O "https://releases.aembit.io/agent_proxy/<version_number>/linux/amd64/aembit_agent_proxy_linux_amd64_<version_number>.tar.gz"
   ```

3. Unpack the archive:

   ```shell
    tar xf aembit_agent_proxy_linux_amd64.<version_number>.tar.gz
   ```

4. Go to the unpacked directory:

   ```shell
   cd aembit_agent_proxy_linux_amd64
   ```

5. *Before* running the installer, copy the `root.crt` from the Agent Controller VM and install it as a trusted CA:

   ```shell
   # Copy root.crt to the Agent Proxy VM, then:
   sudo cp root.crt /usr/local/share/ca-certificates/
   sudo update-ca-certificates
   ```

6. Update `/etc/hosts` to map the Agent Controller and NIA hostnames to their IP addresses:

   ```shell
   sudo vim /etc/hosts
   ```

   Add entries like:

   ```plaintext
   127.0.0.1 localhost
   127.0.1.1 aembit-docs-ap
   172.16.20.41 aembit-docs-ac
   172.16.20.139 aembit-docs-attestor
   ```

7. Run the installer with the required environment variables:

   ```shell
   sudo AEMBIT_AGENT_CONTROLLER=https://aembit-docs-ac:5443 \
     AEMBIT_CLIENT_WORKLOAD_PROCESS_IDENTIFICATION_ENABLED=true \
     AEMBIT_NETWORK_ATTESTOR_URLS=https://aembit-docs-attestor-1:443,https://aembit-docs-attestor-2:443 \
     AEMBIT_LOG_LEVEL=debug \
     ./install
   ```

   > **Multiple Network Identity Attestors**
   >
   > To deploy more than one NIA for redundancy, pass all NIA URLs as a comma-separated list with no spaces. Agent Proxy spreads load across the listed NIAs and fails over to the next URL on per-request failure.

   > **Process identification required**
   >
   > The `AEMBIT_CLIENT_WORKLOAD_PROCESS_IDENTIFICATION_ENABLED=true` flag is required for [Process Hash Attestation](/user-guide/deploy-install/virtual-envs/process-hash-attestation/).

### Configure TLS Decrypt

To get your Aembit Tenant Root CA, perform the following steps:

1. Log in to your Aembit Tenant.

2. In the left sidebar menu, go to **Edge Components -> Certificates**.

3. Click **Download Tenant Root CA**.

4. Once downloaded, copy the Root CA file to your VM where you installed Agent Proxy.

5. On the VM, run the following commands to install the Aembit Tenant Root CA, making sure to replace `<your_tenant_id>` and `<aembit-tenant-root-ca>` with your tenant ID and desired certificate name, respectively:

   ```shell
   sudo apt-get update && sudo apt-get install -y ca-certificates
   sudo wget https://<your_tenant_id>.aembit.io/api/v1/root-ca \
     -O /usr/local/share/ca-certificates/<aembit-tenant-root-ca>.crt
   sudo update-ca-certificates
   ```

## Verify Network Identity Attestation connectivity

After installing and configuring all components, verify that the Agent Proxy can communicate with the Network Identity Attestor.

1. On the Agent Proxy VM, get the system serial number:

   ```shell
   sudo dmidecode -s system-serial-number
   ```

   This returns a value like `VMware-42 18 94 bb 56 30 95 4a-9a ea b1 1c 03 97 72 f9`.

2. Format the serial number for the HTTP request:

   ```shell
   SERIAL=$(sudo dmidecode -s system-serial-number | tr ' ' '+')
   echo $SERIAL
   ```

3. Make a test request to the NIA from the Agent Proxy VM to retrieve an attestation document:

   ```shell
   curl -s -w "\nHTTP Status: %{http_code}\n" \
     --cacert /usr/local/share/ca-certificates/root.crt \
     "https://aembit-docs-attestor:443/netidentity?system_serial=$SERIAL" | jq
   ```

   A successful response returns HTTP status `200` and a JSON document containing:

   ```json
   {
     "document": "eyJub2RlQXV0aG9yaXR5VHlwZSI6IlZNV2FyZSB2Q2VudGVyIi...",
     "signature": "WEMuUJ3/jYCb6fBxj+PU14kJIpIn3d7FXdMQYgc0fs...",
     "signatureAlg": "rsa-sha256",
     "certSerial": "6f:fa:05:ad:45:80:1a:1f:76:f4:54:dc:38:f0:d1:58:80:4e:6d:25"
   }
   ```

4. Decode the attestation document to verify VM metadata:

   ```shell
   curl -s \
     --cacert /usr/local/share/ca-certificates/root.crt \
     "https://aembit-docs-attestor:443/netidentity?system_serial=$SERIAL" \
     | jq -r '.document' | base64 -d | jq
   ```

   This displays the decoded attestation document:

   ```json
   {
     "nodeAuthorityType": "VMWare vCenter",
     "nodeAuthority": "https://vcenter.example.com/",
     "name": "aembit-docs-ap",
     "biosUuid": "421894bb-5630-954a-9aea-b11c039772f9",
     "instanceUuid": "50188c24-76c3-536e-66ac-a0fafb2d912f",
     "macType": "ASSIGNED",
     "macAddress": "00:50:56:98:f1:1d",
     "issuedAt": "2025-12-11T23:24:10.023638148+00:00",
     "expiresAt": "2025-12-12T00:24:10.023638148+00:00"
   }
   ```

5. Verify the MAC address matches the Agent Proxy VM’s network interface:

   ```shell
   ip link show | grep -A1 "ens"
   ```

   The `link/ether` address should match the `macAddress` in the attestation document.

### Troubleshooting verification failures

| Error                       | Cause                 | Solution                                               |
| --------------------------- | --------------------- | ------------------------------------------------------ |
| `403 Forbidden`             | MAC address mismatch  | Ensure NIA and Agent Proxy are on the same L2 segment. |
| `Connection refused`        | NIA not running       | Check `systemctl status aembit_netid_attestor`         |
| `Certificate verify failed` | TLS certificate issue | Verify `root.crt` is installed in the CA trust store   |
| `Could not resolve host`    | Hostname not mapped   | Check `/etc/hosts` has the NIA hostname entry          |

## Set up Access Policy in Aembit Cloud

### Client Workload

Create a Client Workload to represent the workloads running on your VMware VMs.

1. Go to **Client Workloads** in the left sidebar.

2. Click **+ New**.

3. Enter a **Name** (for example, “VMware VM Workloads”).

4. Add one or more **Identifiers** to match your workloads. Common options for VMware environments:

   * **Hostname**: Match VMs by their hostname
   * **Process Name**: Match specific applications running on VMs
   * **Source IP**: Match VMs by their IP address range

5. Click **Save**.

> **Matching strategies**
>
> For VMware environments, consider using:
>
> * **Hostname patterns**: Match groups of VMs with similar naming conventions
> * **Multiple identifiers**: Combine hostname and process name for more specific matching

For more information about Client Workload identifiers, see [Client Workload Identifiers overview](/user-guide/access-policies/client-workloads/identification/).

### Trust Provider

Create a Trust Provider to verify attestation documents signed by the Network Identity Attestor. This Trust Provider uses the NIA’s **signing certificate** (not the TLS certificate).

Before creating the Trust Provider, using your company’s PKI solution, issue an RSA key pair and a certificate usable for digital signatures. This certificate must meet the requirements outlined in [Certificate requirements](/user-guide/deploy-install/virtual-envs/reference-network-identity-attestation#certificate-requirements).

1. Log in to your Aembit Tenant.
2. Go to **Trust Providers** in the left sidebar.
3. Click **+ New**.
4. Enter a **Name** (for example, “NIA Attestation Trust Provider”) and optional **Description**.
5. For **TRUST PROVIDER**, select **[Certificate Signed Attestation](/user-guide/access-policies/trust-providers/certificate-signed-attestation-trust-provider)**.
6. Click **+ Add**, and paste the contents of your NIA signing certificate (`signing.crt`) or upload the file.
7. Click **Save**.

> **Multiple certificates for rotation**
>
> You can add multiple certificates to the same Trust Provider. This is useful for:
>
> * **Key rotation**: Add both old and new certificates during rotation periods
> * **Multiple NIA instances**: If different network segments use different signing keys

For more information about Trust Providers, see [Trust Providers overview](/user-guide/access-policies/trust-providers/).

### Credential Provider

Configure a Credential Provider to generate tokens that include the process hash for Azure Entra ID federation. You can use either JWT-SVID Token or OIDC ID Token.

> **Operational note**
>
> You’ll likely need to have your Azure Entra ID application open in another browser tab to copy values during this setup. Don’t save and exit until you’ve completed both the Credential Provider and Azure Entra ID federated credentials configuration.

#### Option 1: JWT-SVID token (recommended)

1. Go to **Credential Providers** in the left sidebar.

2. Click **+ New**.

3. Enter a **Name** (for example, “Azure Entra JWT-SVID”).

4. For **Credential Type**, select **JWT-SVID Token**.

5. Configure the following:

   * **Subject**: Select **Dynamic** and enter:

     ```plaintext
     spiffe://<TENANT_ID>.aembit.io/azure/<AZURE_APP_CLIENT_ID>/${client.executable.hash.sha256}
     ```

   * **Signing algorithm**: RSASSA-PKCS1-v1\_5 using SHA-256

   * **Audience**: `api://AzureADTokenExchange`

6. Click **Save**.

#### Option 2: OIDC ID Token

1. Go to **Credential Providers** in the left sidebar.

2. Click **+ New**.

3. Enter a **Name** (for example, “Azure Entra OIDC”).

4. For **Credential Type**, select **OIDC ID Token**.

5. Configure the following:

   * **Subject**: Select **Dynamic** and enter:

     ```plaintext
     <TENANT_ID>.aembit.io/azure/<AZURE_APP_CLIENT_ID>/${client.executable.hash.sha256}
     ```

   * **Signing algorithm**: RSASSA-PKCS1-v1\_5 using SHA-256

   * **Audience**: `api://AzureADTokenExchange`

6. Click **Save**.

> **Dynamic vs literal subjects**
>
> * **Dynamic subject**: Includes the process hash (`${client.executable.hash.sha256}`). This binds credentials to specific executables.
> * **Literal subject**: Static value that must match Azure Entra ID configuration exactly
>
> Dynamic subjects provide stronger security by ensuring only approved binaries can obtain credentials.

For more information, see:

* [Create a JWT-SVID Token Credential Provider](/user-guide/access-policies/credential-providers/spiffe-jwt-svid/)
* [Create an OIDC ID Token Credential Provider](/user-guide/access-policies/credential-providers/oidc-id-token/)
* [Dynamic Claims for OIDC and JWT-SVID](/user-guide/access-policies/credential-providers/advanced-options/dynamic-claims-oidc/)

### Configure Azure Entra ID federated credentials

Before Aembit can authenticate your workloads to Azure, configure Azure Entra ID to trust Aembit as a federated identity provider. Create federated credentials in your Azure application that accept the

SPIFFE IDs generated by Aembit.

> **Required for NIA with Azure Entra ID**
>
> NIA requires this Azure-side configuration to work with Azure Entra ID. Without federated credentials, Azure rejects the JWT tokens issued by Aembit.

#### Configure federated credentials in Azure

> **Operational note**
>
> You’ll likely need to have your Aembit Credential Provider configuration open in another browser tab to copy values during this setup. Don’t save and exit until you’ve completed both the Credential Provider and Azure Entra ID federated credentials configuration.

1. Sign in to the [Azure Portal](https://portal.azure.com).

2. Go to **Microsoft Entra ID** > **App registrations**.

3. Select your registered application (or create one if needed).

4. Go to **Certificates & secrets** > **Federated credentials**.

5. Click **Add credential**.

6. For **Federated credential scenario**, select **Other issuer**.

7. Configure the following:

   * **Issuer**: `https://<TENANT_ID>.aembit.io` (your Aembit tenant URL)

   * **Subject identifier**: The SPIFFE ID from your Credential Provider, for example:

     ```plaintext
     spiffe://<TENANT_ID>.aembit.io/azure/<AZURE_APP_CLIENT_ID>/<PROCESS_HASH>
     ```

   * **Name**: A descriptive name (for example, “aembit-curl-workload”)

   * **Audience**: `api://AzureADTokenExchange`

8. Click **Add**.

> **Finding the correct subject identifier**
>
> To find the exact SPIFFE ID to use:
>
> 1. Make a test request through Agent Proxy to Azure (this fails initially)
> 2. Check the Azure error response - it contains the exact subject identifier Aembit sent
> 3. Copy this value and use it as the **Subject identifier** in your federated credential
>
> This ensures the subject identifier matches exactly, including the process hash.

#### Multiple federated credentials for different binaries

When using [Process Hash Attestation](/user-guide/deploy-install/virtual-envs/process-hash-attestation/), each unique executable binary requires its own federated credential in Azure. This is because the process hash in the SPIFFE ID changes with each different binary.

For example, if you have three different applications that need Azure access:

* `app-service-1` → Create federated credential with its specific process hash
* `app-service-2` → Create federated credential with its specific process hash
* `data-processor` → Create federated credential with its specific process hash

This provides fine-grained security: only approved binaries can obtain Azure credentials.

For complete Azure Entra ID configuration details, see [Configure an Azure Entra Workload Identity Federation (WIF) Credential Provider](/user-guide/access-policies/credential-providers/azure-entra-workload-identity-federation/).

### Server Workload

Configure Azure Entra ID as the Server Workload to enable workload identity federation.

1. Go to **Server Workloads** in the left sidebar.

2. Click **+ New**.

3. Enter a **Name** (for example, “Azure Entra ID Token Endpoint”).

4. Configure the following:

   * **Host**: `login.microsoftonline.com`
   * **Port**: `443`
   * **Forward to Port**: `443`
   * **TLS**: Enabled
   * **App Protocol**: `OAuth`
   * **URL Path**: `/<AZURE_TENANT_ID>/oauth2/v2.0/token`

5. For **Authentication**:

   * **Method**: OAuth Client Authentication
   * **Scheme**: POST Body Form URL Encoded

6. Click **Save**.

### Test the end-to-end flow

After configuring all Access Policy components, test the complete flow from the Agent Proxy VM:

```shell
curl --location --request POST \
  'https://login.microsoftonline.com/<AZURE_TENANT_ID>/oauth2/v2.0/token' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=<AZURE_APP_CLIENT_ID>' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode 'scope=https://management.azure.com/.default' \
  -x http://localhost:8000 | jq
```

A successful response returns an access token:

```json
{
  "token_type": "Bearer",
  "expires_in": 3599,
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIs..."
}
```

If the request fails with a federated credential error, verify that you have [configured Azure Entra ID federated credentials](#configure-azure-entra-id-federated-credentials) with the correct subject identifier.

## Upgrade Network Identity Attestor

To upgrade an existing installation, use the `--upgrade` flag:

```shell
sudo ./install --upgrade
```

## Uninstall Network Identity Attestor

```shell
sudo ./uninstall
```

This stops the service, removes all related files, and cleans the environment.

## Troubleshooting

* **Missing Required Variables:** The installer fails with a clear error if any required environment variable is missing or empty.

* **Service Fails to Start:** Check logs for errors related to invalid log level or missing certificates.

* **Agent Proxy can’t connect:** Verify `/etc/hosts` mapping, network connectivity, and that you can reach the service on the configured port.

* **Attestation Document Not Accepted:** Register the public key from the signing certificate in the Trust Provider.

* **Log Rotation:** Configure `/etc/systemd/journald@aembit_netid_attestor.conf` for log rotation. Example:

  ```plaintext
  [Journal]
  Storage=persistent
  Compress=true
  SystemMaxFileSize=1M
  SystemMaxFiles=12
  ```

  Restart with:

  ```shell
  sudo systemctl restart systemd-journald@aembit_netid_attestor.service
  ```

* **Upgrades:** Aembit supports upgrades to newer versions; downgrades to older versions aren’t supported.

* **MAC Address Issues:** Enable MAC spoofing protection in your VMware network segment.

## Next steps

After deploying Network Identity Attestor, configure monitoring to track health and performance. See [Monitor Network Identity Attestor](/user-guide/deploy-install/virtual-envs/monitor-network-identity-attestor).