Overview
This article provides a high-level diagnostic framework for troubleshooting instances where an Access Policy fails to inject credentials into a workload request. Because credential injection depends on the alignment of multiple Aembit components, this guide establishes a logical "Entry Point" for systemic investigation.
Relates To
Section: Administration / Policy Governance
Core Components: Access Policy, Trust Provider, Credential Provider, Client Workload, Server Workload
Error State: Workload requests are reaching the agent proxy but lack the required auth headers/tokens.
Cause (Symptom)
The primary symptom is a failure to authorize at the target service, despite an active Access Policy. This indicates a breakdown in the "Identity-to-Credential" exchange.
Investigation Paths: To isolate the failure, administrators should validate the three primary pillars of the policy in the following order:
Path 1: Workload Identity (The "Who")
Question: Is the workload successfully attesting its identity?
Check: Verify the Trust Provider. If the workload cannot prove who it is, the Access Policy request will fail.
Path 2: Policy Conditions (The "How")
Question: Does the request match the defined Access Policy conditions?
Check: Validate the IP, Port, and Hostname defined in the policy against the actual request metadata. A mismatch here prevents the policy from being applied.
Path 3: Credential Provider (The "What")
Question: Is the Credential Provider configured to requirements?
Check: Ensure the Credential Provider has valid credentials, format, metadata, etc.
Solution
The Diagnostic Framework
If an Access Policy is fails, follow this triage flow to identify the specific point of failure:
Path 1: Access Authorization Events (The "Policy" Check) Authorization events evaluate the successful implementation of access management for your workloads.
Location:
Reporting>Access Authorization EventsFilter Strategy: * Timespan: Narrow to the specific window of the failed request.
Severity: Filter by 'Warning' and 'Error' to isolate distinct operational failures.
Analysis: Drill down into the specific event. Review the 'outcome' field. This will indicate if the request was denied due to an invalid Access Policy configuration or a missing Credential Provider.
Path 2: Workload Events (The "Interaction" Check) Workload events provide a detailed reference for the interaction between the Client Workload and the Server Workload.
Location:
Reporting>Workload EventsFilter Strategy: Use 'Warning' and 'Error' to identify communication breakdowns or identity attestation issues.
Analysis: Review the 'outcome' and related output sections. These logs capture the "handshake" between workloads and can reveal if the Client Workload failed to prove its identity before the policy was even evaluated.
1. Severity Audit Always review 'Warning' selections first. Warnings often capture "Soft Failures" (like a policy being ignored due to a minor port mismatch) that don't always trigger a hard 'Error'.
2. Drill-down Validation Within the body of any failed request in the output, look for the "Reason Code." This is a valuable data point for an end-user to determine which component to fix accordingly.