Install checks · Docs

Setup does nearly all of the install. A few things only you can do, because AWS puts them behind a person or an account that Warden does not hold. Each is a guided step: a card with a headline, one sentence, the exact place in the AWS console, a Check button that only reads, and the result. They appear in onboarding where they first matter, and on the console’s Install page afterwards.

Check never runs in the console’s role. It invokes wardensec-checks, a function with its own read-only role. Its input is one check id from a fixed list: no address and no account id from the caller. It runs at most once per check per minute, and where the last scan already holds the fact, Check shows that fact and its time instead of calling AWS.

The guided steps

Step	Why AWS makes you do it	What Check reads
Bedrock model access, per model a role needs	Model access is granted per account in the Bedrock console.	The model and inference-profile lists, and a one-token probe per chosen model, at most 10 probes a day, counted in the agents’ day budget. See Bedrock access.
DNS delegation, when the parent zone is outside Route 53	The registrar is outside AWS.	That the four name-server records resolve to the hosted zone’s servers, from two public resolvers.
E-mail subscription confirmation	SNS needs the recipient’s click.	That the subscription is no longer pending confirmation.
EKS authentication mode allows access entries, per cluster	Changing a cluster’s mode is the cluster owner’s decision.	The cluster’s authentication mode.
Organizations trusted access for StackSets, for organization estates	Only the management account may enable it.	When the hub is the management account, the service-access list; otherwise the result of the last StackSet operation, with “Ask your organisation’s administrator”.
The one-line install, the uninstall’s final command, and recovery when every key is lost	These need administrator credentials, which Warden never holds.	Install: health. Uninstall: the progress file. Recovery: the regenesis record.
Defend at once from onboarding (optional)	The read-back must be read where the page cannot write.	The read-back result in the install journal.
Getting the console back: `warden refresh` and `warden door reissue <e-mail>`	When the console or its door is broken, nothing inside the console can mend it.	`refresh` re-applies the effective state; `door reissue` mails a new temporary password to a person the record names. See Recovery.

The steps behind setup

The headings below are the install’s steps in the order setup performs them. Each says what the step is for and what setup does in its place, so you can see why a Check fails or follow the same path by hand. Other pages link to these headings by name.

Step 1 — Get the code and prove the toolchain

Not part of the setup path. The launcher verifies the release it runs, so there is no repository to clone and no toolchain to prove.

Step 2 — Decide the names, and create the values file

Setup asks the three questions that matter: the console’s name, your e-mail, and how long to keep the record. It discovers the rest. The install id is drawn once, by the first stack that is created, and read back from the hub stack after that.

Step 3 — Choose the hub account, and enable the organization policy types

The hub account holds the hub role, the state bucket, the ledger and the secrets, and it must be the account that owns the EKS cluster Warden runs in. The second half needs organization-admin rights and applies only when the account is in an organization.

Step 4 — Repository governance and CI

Not part of the setup path. There is no fork and no clone, so no repository of yours governs what runs.

Step 5 — Cluster prerequisites

Setup registers the IAM OIDC provider, installs the Pod Identity agent and creates the dedicated node group. It refuses a control plane below Kubernetes 1.30 and a managed network plugin with network policy enforcement off, and names the one command that fixes each.

Step 6 — The four operator roles

The hub stack takes four role names as parameters and writes them into the state-bucket and secret policies, so the roles exist first. None may begin with Wardensec-.

Step 7 — Mint the ExternalId

One random identifier per install. It is a confused-deputy discriminator on every member trust, not a secret, but it must not be lost.

Step 8 — VPC endpoints: create or reuse

The scanner’s credentials are denied unless a request arrives through a pinned VPC endpoint or the egress proxy’s address. Setup offers to reuse endpoints your VPC already has and prices each one.

Step 9 — The hub stack

One Warden per estate. Every name the stack creates is fixed, except the names of what outlives an uninstall, which carry the install id. Setup reads what is already there before it creates anything.

Step 9b — The flow-log sensor (optional)

Optional. If your estate already delivers its flow logs to a bucket, Warden’s own network sensor can read them in aggregate and feed the open-and-used and scan checks. Skip it and nothing changes.

Step 10 — The hub-global stack

Changes to IAM are recorded in us-east-1, so the watchers for the hub and member roles live there, with their own alarm topic.

Step 11 — The spoke StackSet

One member role per account you want read. When you have an organization trail, include the hub account and the account that owns the trail. Without organizational units, use the self-managed StackSet model.

Step 12 — The organization SCP, RCP and delegation

Needs organization-admin rights. The service control policy and resource control policy only protect the member roles; they are applied last, because they are rendered from the hub stack’s outputs.

Both alarm topics need a subscription a person has confirmed. An unconfirmed subscription raises an alarm on every run, because silence is the failure the dead-man alarm exists to catch.

Step 14 — Decide the CloudTrail volume source

CloudTrail is always read through LookupEvents for the tamper and watch families. This decision only chooses the volume source a few controls use.

Step 15 — Fill the values file and render

With warden setup none of this is done by hand: the gate renders the verified release’s chart from its own reads, and setup shows that plan before it applies it.

Step 16 — Build the image and pin the digest

Not part of the setup path. There is no image to build: setup installs the release it verified.

Step 17 — Deploy the manifests

Setup applies the chart in the wardensec namespace of your cluster.

Step 18 — Verify what you installed

Seven checks, one per class of object, in an order where each failure would otherwise be masked by the next.

Step 19 — The first run

The first run reads your estate and posts a baseline, not an alarm.

Step 20 — Read the first digest, and prove the outbound path

The first digest says that it is the picture the estate starts from. Reading it proves the outbound path.

Step 21 — Open the board

Every run rewrites a static board inside the state bucket, beside the bundles, under the same bucket policy and key.

Step 22 — The console

The console’s front door and its people. The load balancer, the sign-in pool and the checklist are created by setup; the first keeper registers a passkey. See Onboarding. Slack is a channel a keeper adds in the console, in Settings under Alerts, by pasting an incoming-webhook URL: there is nothing to install for it. See Settings.