Deploy the evidence path¶

Activate the configured connector or accepted provider export so the platform can classify and process its evidence. Invocation-grade records enter Stage A before inference; only eligible unresolved ownership relationships reach RAIL (Resource Attribution & Inference Layer) in Stage B. See Docs authority & product state.

Execute this step in SaaS guided setup. For self-hosted deployments, use the same /domains/adoption/onboarding path on your own instance host.

Steps¶

Role: Engineer with deployment access.

For AWS, Google Cloud, or Azure, you applied the module and registered its outputs in step 2 through your cloud guide; this step does not apply it again. Before you activate, confirm that the local boundary check for your cloud meets its pass rule against the applied module. Rerun it from the extracted infra/<cloud>/onboarding/ directory, which holds your terraform.tfvars and Terraform state, if the module, its variables, or any role assignment changed since the apply. The local check inspects what the module granted, from your side of the trust boundary. Automated credential validation in guided setup runs as Venturi’s own identity, which is the identity the module trusts. It runs the positive read probes and confirms that the deny-expected write probes fail, so it is the read and denied-write proof for activation.

AWSGoogle CloudAzure

Bash

cd infra/aws/onboarding
ROLE_ARN="$(terraform output -raw role_arn)"
ROLE_NAME="${ROLE_ARN##*/}"
aws iam list-attached-role-policies --role-name "$ROLE_NAME" \
  --query 'AttachedPolicies[].PolicyArn' --output json
for POLICY in $(aws iam list-role-policies --role-name "$ROLE_NAME" \
    --query 'PolicyNames[]' --output text); do
  echo "$POLICY"
  aws iam get-role-policy --role-name "$ROLE_NAME" --policy-name "$POLICY" \
    --query 'PolicyDocument.Statement' --output json
done
aws iam simulate-principal-policy \
  --policy-source-arn "$ROLE_ARN" \
  --action-names iam:CreateUser s3:CreateBucket ce:CreateAnomalyMonitor \
    cloudwatch:PutMetricData logs:CreateLogGroup cur:PutReportDefinition \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' \
  --output table

The caller needs iam:ListAttachedRolePolicies, iam:ListRolePolicies, iam:GetRolePolicy, and iam:SimulatePrincipalPolicy. The policy listing is the complete check: it shows every managed and inline policy on the role. The simulator is a spot check that evaluates only the 6 write actions the module’s verify.sh probes.

Pass: the attached-policy list is []; the inline policies (3 with Bedrock access enabled, 2 without) contain only Allow statements for the access-boundary read actions; and no simulator row shows allowed, each showing implicitDeny or explicitDeny. The read actions are listed in the AWS access boundary.

Do not run the module’s scripts/verify.sh with your own credentials. It starts by assuming the role, and the role’s trust policy admits only Venturi’s principal with your tenant’s external ID, so the script stops with FAIL: could not assume role. Automated credential validation runs those read and deny-expected write probes as Venturi’s principal.

Bash

cd infra/gcp/onboarding
PROJECT_ID="<project_id>" \
SERVICE_ACCOUNT_EMAIL="$(terraform output -raw service_account_email)" \
./scripts/verify.sh

The verifier confirms that the Venturi service account exists and has no user-managed keys, prints a role: line for each project-scope role binding, and checks that the Workload Identity Pool is present. Before you begin lists the roles the verifier needs.

Pass: the script exits 0 with no SEC or MISS line, and its project-scope role lines are exactly role: roles/monitoring.viewer, role: roles/logging.viewer, and role: roles/serviceusage.serviceUsageConsumer, the project roles the module grants with billing_dataset_only = true. Any other role: line, including roles/bigquery.dataViewer, roles/iam.serviceAccountTokenCreator, or roles/iam.workloadIdentityUser, is a security finding even though the script prints it as OK: its allowlist accepts those roles, so a clean allowlist result alone does not prove that no write-capable role is bound. The BigQuery write probe runs only when your identity can impersonate the service account; without that grant it reports SKIP, which does not fail the check. See Verify & confirm.

Bash

cd infra/azure/onboarding
CLIENT_ID="$(terraform output -raw client_id)"
OBJECT_ID="$(terraform output -raw object_id)"
export CLIENT_ID OBJECT_ID
az logout
az login
az account set --subscription "<subscription_id>"
az account show --query user.name --output tsv
SUBSCRIPTION_ID="<subscription_id>" ./scripts/verify.sh
az role assignment list --assignee "$OBJECT_ID" --all --output table

Capture CLIENT_ID and OBJECT_ID while you are still signed in as the setup operator: a Reader-only identity cannot read Terraform state kept in the azurerm backend. Then run the verifier and the listing from a separate az login session whose identity holds only the Reader role on the subscription, never as the setup principal. At the az login prompt, sign in as that Reader-only identity, and confirm the name that az account show prints before you continue.

The verifier’s write probes run as the calling identity, not as the Venturi service principal. Under Owner, User Access Administrator, or Role Based Access Control Administrator, the role-assignment probe can succeed, which briefly assigns Contributor to the service principal before the verifier removes it. Under Owner, the resource-group probe also succeeds and leaves a venturi-verify-must-fail-* resource group behind. The verifier reports either case as a security finding and exits with status 1. Under Reader, the probes are denied.

The service principal’s boundary is proven by the --all listing and by automated credential validation. The script’s role allowlist also accepts roles the module never grants, including Reader and Data Access, which can read and write all data in a storage account through its account keys, and Billing Reader, so a clean script run alone does not prove the boundary.

Pass: exit 0 with no SEC or MISS lines; with APIM access enabled, no role: Log Analytics Reader line; and an --all listing that shows only Reader, Cost Management Reader, and Monitoring Reader on the subscription, plus Log Analytics Reader on the named workspace and Azure Event Hubs Data Receiver on the named namespace when those grants are enabled. In the client-secret fallback, a MISS line for the absent federated credential is expected; resolve every other MISS.

Then, in guided setup, confirm that automated credential validation passed, rerunning it if anything changed since step 2, activate the connector, and run the 1st readiness probe. For a provider export file, confirm the accepted import and activate its period instead.

Success evidence¶

The local boundary check for your cloud meets its pass rule against the applied module. The deployment record contains the applied artifact version, read-only boundary result, automated credential validation, and successful 1st readiness probe. The source is ready for platform evidence processing. Activation does not promote discovery observations or aggregate usage into invocations, or make every record eligible for inference.

Recovery¶

Use the failed probe to correct the exact role, trust condition, network path, or source configuration. Reapply only reviewed changes, then rerun the local boundary check and automated credential validation. Do not activate while automated credential validation reports any expected read or denied write as unproven. Any successful write response is a security finding: stop, remove the excess permission from the module or role assignment, and reapply before you rerun the checks.

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details

Docs feedback: Deploy the evidence path
Page: https://docs.venturi.systems/onboarding/deploy/