CCNA Vault Security Model Questions

The num_uses parameter caps how many times a SecretID can be used for login. Setting it to 1 enforces single-use semantics, so the SecretID is consumed on first authentication and rejected thereafter, matching the stem's requirement.

A token_ttl of 87600h (ten years) means issued tokens effectively never expire, so a leaked credential remains valid indefinitely. This defeats AppRole's short-lived credential model and removes the automatic revocation window that limits blast radius after compromise.

The injector operates as a Kubernetes Mutating Admission Webhook, intercepting pod creation requests and mutating the pod spec to add an init container and sidecar. This satisfies the scenario's requirement for automatic secret injection without application code changes, since the webhook applies annotations to pods at admission time.

Setting secret_id_num_uses to 1 restricts each SecretID to a single use, preventing replay. Configuring secret_id_bound_cidrs to the application's subnet ensures the SecretID is only valid from that network range, binding the authentication material to the application's location. This directly satisfies both requirements without affecting other roles.

Auto-unseal with a cloud KMS seal stanza delegates protection of the master key to the KMS. On startup, Vault calls the KMS to decrypt the stored wrapped master key and unseals without operator intervention. This satisfies the requirement for automatic recovery after a full restart while keeping the master key protected by an external root of trust.

Short TTL and max TTL limit the window in which a stolen token can be used. Even if an attacker obtains the token, it will expire soon, and the max TTL prevents indefinite renewal. This directly reduces the blast radius by forcing frequent re-authentication, which is a standard least-privilege and least-duration practice for external partners.

The Kubernetes auth method reads the pod's mounted service account token at the default path and submits its contents as the JWT. This satisfies the stem's requirement for the value automatically sent to the Vault server.

Configuring the Kubernetes API server's CA certificate lets Vault verify the API server's identity when the load balancer terminates TLS, since Vault can no longer rely on the client-supplied TLS chain. The `kubernetes_ca_cert` parameter satisfies the stem's requirement to validate `kubernetes_host` independently of the load balancer's terminated connection.

The secret_id_bound_cidrs field restricts which CIDR blocks may present a SecretID during AppRole login, so setting it enforces the stem's source-address constraint. Requests from outside the listed ranges are rejected even with a valid SecretID.

ACL policies in Vault define who can access specific paths, including auth method configuration endpoints. By creating and attaching appropriate policies to tokens or entities, the administrator can restrict who can modify the auth method configuration. This is the standard way to control access to Vault's API endpoints.

Configuring `kubernetes_host` and `kubernetes_ca_cert` lets Vault reach the Kubernetes API server and trust its TLS certificate, enabling the TokenReview call that validates the pod's service account token. Without these, Vault cannot contact the cluster, so token verification fails.

Destroying the specific SecretID invalidates only that credential, leaving the RoleID and all other active tokens untouched. Vault's AppRole auth method supports per-SecretID destruction via `auth/approle/role/:role_name/secret-id/destroy`, which satisfies the stem's constraint of immediate, targeted revocation without broader impact.

Audit logs record each Kubernetes Auth login attempt and the precise validation error, such as an invalid service account token or JWT signature mismatch. This directly satisfies the stem's need to diagnose why pods fail authentication, since the failure is captured server-side rather than in pod logs.

For seal wrapping, Vault uses a specific key in the HSM, identified by the key_label. If the key_label is incorrect or missing, Vault cannot locate the seal wrap key, leading to the reported failure. The seal stanza must specify the correct key_label that matches the key created in the HSM.

The Vault Agent injector runs as a sidecar that authenticates pods and delivers tokens via a shared in-memory volume, so service account tokens are never written to disk or exposed to application containers, directly mitigating token theft in the Kubernetes integration.

Batch tokens are self-contained, encrypted with the cluster's keyring, and include the policies and metadata needed for authorization. Any node in the cluster can validate them without reading from storage, which is why they work across performance standbys. However, because they are not stored, individual revocation is not possible; only the entire batch or the underlying role/lease can be revoked.

The `token_ttl` setting specifies the initial time-to-live for tokens issued upon successful AppRole login, directly governing the authentication session's duration before renewal or expiry. This satisfies the stem's requirement by defining how long the issued token remains valid, after which the client must reauthenticate or renew.

token_bound_cidrs is the correct parameter because it restricts token usage to the specified CIDR blocks. When a token is created with token_bound_cidrs set to 10.0.0.0/8, Vault will reject any request using that token from an IP outside that range. This directly addresses the scenario by binding the token to the corporate network, preventing unauthorized use from other locations.

SecretIDs support `num_uses`, capping how many times a single SecretID can authenticate before Vault invalidates it. This directly satisfies the stem's constraint on SecretID management, limiting exposure if a SecretID leaks. Combined with short TTLs and response wrapping, it enforces single-use or limited-use authentication for AppRole clients.

Response Wrapping returns a single-use wrapping token that the VM unwraps to retrieve the real Vault token, letting provisioning deliver credentials without exposing them in logs or templates. This satisfies secure introduction for dynamic infrastructure.

Setting a distinct `kubernetes_host` per cluster binds each Kubernetes auth mount to a single API server endpoint. Vault validates the service account token's issuer and audience against that host, so a token minted in Cluster B fails authentication at Cluster A's mount, satisfying the cross-cluster isolation requirement.

The service account token's scope determines which Kubernetes APIs and audiences it can access, so a narrowly scoped token limits what a compromised pod could leverage against Vault's Kubernetes auth backend, directly reducing token compromise risk.

'token_bound_cidrs' binds the issued Vault token to the specified CIDR blocks, so the token is only usable from source IPs within those ranges. This satisfies the scenario's requirement to limit token use by network origin, enforced by Vault at request time independently of Kubernetes.

Binding `secret_id_bound_cidrs` restricts which network ranges may redeem a SecretID, so a stolen SecretID is useless from an attacker's host. This directly satisfies the stem's security-hardening goal by adding a source-IP constraint to AppRole authentication, complementing RoleID and SecretID without altering the core login flow.

The Transit secrets engine is a cryptographic service: clients submit plaintext to Vault, Vault encrypts it using a named key and returns only the ciphertext. The plaintext is processed in memory and is not written to Vault's storage backend, so the auditor's requirement is satisfied. This is the core security value of Transit for data-at-rest encryption outside Vault.

Response wrapping returns a single-use wrapping token instead of the actual secret, so the unwrapping token can be delivered safely through automation. Only the intended recipient can unwrap it once, preventing interception or replay during the Secure Client Introduction phase.

Token replication is a feature of Vault Enterprise that replicates tokens from the primary to DR replicas. After promotion, clients can continue using their existing tokens without re-authenticating, as the tokens are already present on the DR replica. This ensures minimal disruption during failover.

The reviewer_service_account is the Kubernetes service account whose token Vault uses to call the TokenReview API, validating client JWTs presented during login. It satisfies the constraint of authenticating clients without granting Vault broad cluster permissions.

The audience field validates the 'aud' claim inside the service account JWT presented by the pod, ensuring Vault only accepts tokens minted for its own configured audience rather than any cluster token. This binds authentication to the intended relying party, satisfying the requirement that tokens be scoped to Vault specifically.

Enabling an audit device ensures that all requests, including cryptographic operations on the Transit engine, are logged. This provides an audit trail for compliance and detection of unauthorized use. It satisfies the requirement that cryptographic operations are audited.

A wrapped response delivers the SecretID as a single-use token; the application unwraps it once, so interception yields nothing reusable. The specific TTL bounds exposure, satisfying the requirement that secret delivery remains uncompromised for the periodically fetching legacy application.

Tokens are namespace-scoped. A token created in team-a is not valid for API calls in team-b; it cannot be used to authenticate to team-b's secrets engine. Even if the policy path matched, the token's namespace context prevents access. Thus the read fails due to namespace isolation.

Auto-unseal requires the HSM to access the same key that was used during initialization to encrypt the root key. If the slot or partition is incorrect, Vault cannot decrypt the root key and falls back to manual unseal. Verifying the slot and key label is essential when troubleshooting HSM auto-unseal failures.

When Vault fails to start with an HSM seal, the first step is to examine the server logs, which will indicate if the PKCS#11 library cannot be loaded or if there is an authentication failure with the HSM. Verifying the library path and HSM credentials is essential to resolve connectivity issues.

Wildcards are supported in `bound_service_account_names`, letting one role match many service accounts without listing each individually. This satisfies the stem's requirement that the parameter can target multiple accounts, since patterns such as `web-*` match every service account sharing that prefix, reducing role sprawl across namespaces.