Setting up Aembit in a VMware vSphere environment

This page describes how to set up Network Identity AttestorNetwork Identity Attestor: Network Identity Attestor is an Aembit Edge component deployed in VMware vSphere environments that verifies VM identity through the vCenter API and issues signed attestation documents for workload authentication.Learn more in a VMware vSphere environment for Aembit EdgeAembit Edge: Aembit Edge represents components deployed within your operational environments that enforce Access Policies by intercepting traffic, verifying identities, and injecting credentials just-in-time.Learn more. NIA provides cryptographically verifiable identity for workloadsWorkload: Any non-human entity (application, service, automation, etc.) that needs to access resources.Learn more running in virtualized environments by issuing attestation documentsAttestation Document: An attestation document is a cryptographically signed JSON document containing workload metadata (such as VM name, UUID, and MAC address) that proves a workload's identity. Aembit Cloud verifies the signature to authenticate the workload.Learn more based on VM metadata.

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

1. Agent Controller
2. Network Identity Attestor
3. Agent Proxy

After setting up these components, you’ll configure an Access PolicyAccess Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more in your Aembit TenantAembit Tenant: Aembit Tenants serve as isolated, dedicated environments within Aembit that provide complete separation of administrative domains and security configurations.Learn more to use NIA for workload identity attestation. Your Access Policy consists of the following components:

1. Client Workload
2. Trust Provider
3. Credential Provider that issues JWT SVID tokens to the VMware-based Client Workload from Azure Entra ID
4. Server Workload

Then, you’ll test the end-to-end setup 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 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
    • Agent Proxy - See 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 CloudAembit Cloud: Aembit Cloud serves as both the central control plane and management plane, making authorization decisions, evaluating policies, coordinating credential issuance, and providing administrative interfaces for configuration.Learn more. Device Codes are temporary one-time-use codes valid for 15 minutes.

For more information, see About the Aembit 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:

   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:

   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:

   tar xf aembit_agent_controller_linux_amd64.<version_number>.tar.gz

5. Go to the unpacked directory:

   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:

   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:

   ps aux | grep aembit

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

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:

Prepare TLS certificates for NIA

Before installing Network Identity Attestor, obtain TLS certificates for secure communication. Use custom TLS certificates.

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.

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:

   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:

   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.

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:

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

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

   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:

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

   Expected output should show Digital Signature.

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 or the installation fails.

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

2. Download the Network Identity Attestor release:

   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:

   tar xf aembit_netid_attestor_linux_amd64_1.27.141.tar.gz

4. Go to the unpacked directory:

   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 vCentervCenter: VMware vCenter Server is a centralized management platform for VMware vSphere environments that provides VM lifecycle management, monitoring, and APIs for querying VM metadata such as UUIDs and MAC addresses.Learn more(opens in new tab) credentials file. Include the username and password on a single line, separated by a colon:

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

7. Run the installer with the required environment variables:

   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:

   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:

   sudo systemctl status aembit_netid_attestor

9. Check the logs to confirm successful startup:

   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.

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 identityWorkload Identity: A unique, verifiable identity assigned to a workload by Aembit.Learn more 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:

   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:

    tar xf aembit_agent_proxy_linux_amd64.<version_number>.tar.gz

4. Go to the unpacked directory:

   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:

   # 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:

   sudo vim /etc/hosts

   Add entries like:

   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:

   sudo AEMBIT_AGENT_CONTROLLER=https://aembit-docs-ac:5443 \
     AEMBIT_CLIENT_WORKLOAD_PROCESS_IDENTIFICATION_ENABLED=true \
     AEMBIT_NETWORK_ATTESTOR_URL=https://aembit-docs-attestor:443 \
     AEMBIT_LOG_LEVEL=debug \
     ./install

   Process identification required

   The AEMBIT_CLIENT_WORKLOAD_PROCESS_IDENTIFICATION_ENABLED=true flag is required for 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 -> TLS Decrypt

3. Click Download your Aembit 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:

   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:

   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 by removing spaces and hyphens:

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

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

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

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

   {
     "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:

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

   This displays the decoded attestation document:

   {
     "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:

   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.

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.

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.
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.

Credential Provider

Configure a Credential Provider to generate tokens that include the process hash for Azure Entra ID federation. You can use either JWT-SVIDJWT-SVID: A SPIFFE Verifiable Identity Document in JWT format. JWT-SVIDs are cryptographically signed, short-lived tokens that prove workload identity and enable secure authentication without static credentials.Learn more 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. So 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:

     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:

     <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
• Create an OIDC ID Token Credential Provider
• Dynamic Claims for OIDC and JWT-SVID

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 SPIFFESPIFFE: Secure Production Identity Framework For Everyone (SPIFFE) is an open standard for workload identity that provides cryptographically verifiable identities to services without relying on shared secrets.Learn more(opens in new tab) 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. So 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.
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:

     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, 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.

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 PolicyAccess Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more components, test the complete flow from the Agent Proxy VM:

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:

{
  "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 with the correct subject identifier.

Upgrade Network Identity Attestor

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

sudo ./install --upgrade

Uninstall Network Identity Attestor

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:

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

  Restart with:

  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.