CCNA Securing Workloads Questions

Istiod's control plane watches Istio configuration resources such as AuthorizationPolicy and translates them into Envoy-native configuration, then pushes updates to each sidecar through the xDS protocol. This distribution mechanism satisfies the stem's requirement that policies reach every sidecar without manual intervention or per-pod configuration.

AuthorizationPolicy source.ipBlocks matches the originating IP against the specified CIDR ranges, so only requests from 10.0.0.0/24 are permitted to reach the payments service. Other sources are denied, enforcing the security team's origin restriction at the Envoy layer.

Envoy Proxy runs as the sidecar enforcing AuthorizationPolicy decisions at the workload level. Istiod distributes the policy configuration, but the actual allow or deny enforcement on each request happens inside the Envoy filter chain, satisfying the requirement for workload-level enforcement.

PERMISSIVE mode accepts both mutual TLS traffic from sidecar-injected workloads and plaintext traffic from sources without sidecars, easing migration. It does not enforce mTLS; STRICT is required for that, so plaintext connections remain accepted on the same port.

A RequestAuthentication policy only validates JWTs when one is present; it does not itself reject requests lacking a token. Because no JWT is supplied, the policy performs no validation and the request passes through, satisfying the stem's scenario. Rejection requires a separate AuthorizationPolicy with JWT rules configured.

This rule correctly combines a source principal match with an operation match. The 'from' field restricts the source to the specified SPIFFE identity, and the 'to' field restricts the request to HTTP GET on the exact path. This enforces both identity-based and method/path-based access control in a single AuthorizationPolicy rule.

The trust domain forms the root of the SPIFFE identity URI embedded in every workload certificate, appearing as spiffe://<trust-domain>/ns/... in the SAN. It establishes which identities are trusted within the mesh, so mismatched trust domains reject mTLS handshakes.

The rules.when field holds match conditions evaluated against request attributes, including verified JWT claims via request.auth.claims. This satisfies the constraint of restricting access by claim values, since the JWT must first be validated by a RequestAuthentication policy before those claims are trusted.

from is one of the three rule fields in an Istio AuthorizationPolicy, defining the source of the request via source principals, namespaces, or IP blocks. It satisfies the stem's requirement for a valid rules-section field.

A SPIFFE ID follows the spiffe:// URI form, where the trust domain is the authority component identifying the issuing trust root, followed by the workload path; the trust domain is therefore one of the three constituent parts.

Without any PeerAuthentication policy, Istio's mesh-wide default is PERMISSIVE mode, so sidecars accept both plaintext and mTLS traffic simultaneously. This satisfies the stem's condition of no policy applied, allowing gradual migration without breaking non-mesh clients.

AuthorizationPolicy rules define the allow, deny and custom conditions applied to inbound requests at the workload. This satisfies the constraint because traffic is only accepted when an ALLOW rule matches; absent any matching rule, the request is rejected by default.

Istio evaluates DENY policies before ALLOW policies, so any matching DENY rule blocks the request regardless of an ALLOW rule that would otherwise permit it. This deny-overrides evaluation order satisfies the scenario where both actions exist in the same namespace.

The cacerts resource holds the trusted root certificates Istio uses to validate workloads. Supplying a custom CA's root certificate there lets the mesh trust that authority, satisfying the requirement to define the root certificate for a custom CA.

Under STRICT PeerAuthentication, the client sidecar initiates mTLS handshakes with the destination workload, since plaintext is rejected. This satisfies the stem's constraint by describing the client-side action required when strict mutual TLS is enforced mesh-wide.

The SPIFFE-style identity `cluster.local/ns/default/sa/my-service` is the exact principal format Istio expects in an AuthorizationPolicy, encoding trust domain, namespace and service account. It satisfies the stem's requirement for correct principal syntax, unlike bare service names or DNS hostnames, which Istio cannot match against workload identities.

A PeerAuthentication with a selector targets only the labelled workload's sidecars, overriding the mesh-wide default for that pod. The workload's own policy takes precedence, so it can set mTLS to PERMISSIVE or DISABLE while the global STRICT policy remains for everything else.

Multiple AuthorizationPolicies targeting one workload combine additively: a request is allowed if any policy's ALLOW rule matches, giving OR semantics. This satisfies the stem's union requirement, so adding policies only widens access rather than intersecting it.

A namespace-wide PeerAuthentication policy without a selector applies to every workload in that namespace, taking precedence over the mesh-wide global policy. Istio resolves policy by specificity: namespace-scoped configuration overrides mesh-scoped, satisfying the requirement to supersede the global policy for all workloads in 'default'.

RequestAuthentication only validates JWTs if present, but it does not reject requests without a JWT. To enforce that a valid JWT is required, you must create an AuthorizationPolicy that allows only requests with a validated JWT. This is typically done by matching on the 'requestPrincipals' field, which is populated after successful JWT validation. Without this policy, requests without a JWT would still be allowed, so this step is necessary to block them.

RequestAuthentication supports a workloadSelector, so the JWT validation rules it defines apply only to the pods matching that selector rather than the whole namespace. This satisfies the requirement of scoping authentication policy to specific workloads.

RequestAuthentication validates JWTs presented by clients. The jwksUri points to the JSON Web Key Set endpoint holding the public keys; Envoy fetches these keys to verify each token's signature, ensuring the JWT was issued by the trusted identity provider.

Setting PeerAuthentication's mtls.mode to STRICT in the prod namespace enforces namespace-wide mTLS, rejecting any plaintext or permissive traffic to workloads there. This satisfies the requirement that all workloads accept only mTLS, without per-pod configuration, since STRICT overrides mesh-level defaults for that namespace.

The operation field lists the HTTP methods and exact paths a rule matches, such as GET on /products. It defines the request attributes the policy evaluates, letting you scope authorisation to specific endpoints rather than whole workloads.

The Envoy sidecar retrieves the JSON Web Key Set directly from the URL declared in the RequestAuthentication resource's jwksUri field, caching the keys locally. This satisfies the verification requirement because the sidecar validates JWT signatures itself without routing token checks through an external service.

PeerAuthentication in Istio's security API defines the mTLS mode (STRICT, PERMISSIVE, DISABLE) that the mesh enforces for a workload or namespace. Without it, sidecars default to PERMISSIVE, so plaintext remains accepted and mutual authentication is never guaranteed.

Acts as the CA.

STRICT mode enforces mutual TLS, so plaintext or non-mTLS client connections to the workload are refused at the sidecar proxy. This directly satisfies the scenario's requirement that requests without mTLS be rejected, confirming the PeerAuthentication policy is active and enforcing rather than merely permissive.

Without a sidecar proxy, there is no Envoy instance to enforce Istio's authorization rules, so the policy has no effect on traffic. Istio's control plane distributes policy to sidecars, not to the application itself; absent that enforcement point, requests proceed unauthenticated and unrestricted.

An ALLOW policy with a source.principals match permits only requests whose peer certificate carries the SPIFFE ID cluster.local/ns/payments/sa/payment-processor. Because Istio's default is to deny when any ALLOW policy exists for the workload, all other identities are implicitly rejected. This exactly implements least-privilege, identity-based access in a STRICT mTLS mesh.

An ALLOW action paired with an empty rule set matches every request unconditionally, because no conditions restrict which traffic qualifies. This differs from ALLOW with populated rules, which permits only requests satisfying those specific conditions, and from DENY, which blocks matching traffic.

Listing the PeerAuthentication custom resources across all namespaces queries the live mesh configuration directly, so it reveals every policy currently enforced. The -A flag satisfies the requirement to show policies mesh-wide rather than only those in the current namespace.

root-cert.pem holds the trusted root CA certificate that both workloads and the Istio control plane use to validate peer certificates, anchoring the mTLS trust chain. This satisfies the stem's constraint by providing the common trust anchor for certificate verification.

REDIRECT is an Envoy route action, not an authorization decision, so it cannot appear in an Istio AuthorizationPolicy. The policy's action field accepts only ALLOW, DENY, and CUSTOM, which satisfies the stem's requirement for an invalid action.

PERMISSIVE mode allows the workload to accept both mTLS and plaintext traffic. This satisfies the requirement to enforce mTLS for mesh services while still allowing the legacy service to connect without mTLS. The selector ensures the policy applies only to the 'database' workload. This is the correct configuration for a gradual migration to strict mTLS or for accommodating non-mesh clients.

In ambient mode without sidecars, mTLS and authorisation are handled by the node-level ztunnel proxy rather than per-pod Envoy sidecars. PeerAuthentication policies are therefore enforced by the ztunnel, which terminates and originates the workload traffic on behalf of each pod.

RequestAuthentication validates the JWT signature by fetching signing keys from the issuer's JWKS URI. If the proxy cannot reach that endpoint, key retrieval fails and signature verification cannot complete, so the token is rejected even though the issuer claim itself is correct.

With no AuthorizationPolicy bound to a workload, Istio's default posture is permissive: requests reaching the sidecar are forwarded without authorisation checks. This satisfies the stem's "no policy present" constraint, since enforcement only activates once a policy selects the workload. Traffic is therefore allowed by default.

STRICT mode rejects plaintext traffic, so every workload in the namespace must present a sidecar-managed certificate. A legacy service without an injected sidecar cannot complete the mTLS handshake, since no Envoy proxy terminates TLS on its behalf. The namespace-wide policy therefore blocks it, satisfying the stem's encryption constraint.

The 'when' field in an authorization policy accepts conditions evaluated against request attributes, and 'request.headers' exposes individual header values for matching. This lets you permit or deny traffic only when the named header is present, satisfying the requirement to restrict access based on a specific request header.

Egress Gateways can handle mTLS termination/origination for external traffic.

RequestAuthentication validates the JWT against the specified issuer, while AuthorizationPolicy enforces that only requests carrying a token from that issuer are permitted. Together they satisfy the constraint of restricting the service to a single trusted JWT issuer.

An AuthorizationPolicy without an action field defaults to ALLOW, satisfying the stem's constraint that no explicit action is declared. Istio's authorisation engine treats the absence of an action as permissive, so matching requests pass through. This differs from DENY, which requires explicit specification, making ALLOW the implicit baseline behaviour.

istioctl proxy-config secret <pod-name> queries the Envoy instance's secret configuration, showing the SDS-delivered certificate, its validity and the CA chain used for mTLS. This satisfies the stem's constraint by confirming the pod holds an active mTLS certificate.

A PeerAuthentication with mode PERMISSIVE and a workload selector overrides the namespace-wide STRICT policy for that specific workload only, allowing plaintext alongside mTLS. The legacy service, unable to present certificates, can then communicate while the rest of the namespace remains strict.

RequestAuthentication supports an array of jwtRules, and each rule can define a distinct issuer and jwksUri. Istio will attempt to validate an incoming JWT against all configured rules, accepting the token if it matches any rule. This is the correct way to support multiple issuers with different key sets.

The 'when' condition with key request.auth.claims[custom-claim] matches the validated JWT claim against the listed values, so the policy allows or denies based on that claim. This satisfies the stem's constraint of authorising users via a custom JWT claim.

'RequestAuthentication' defines how Istio validates credentials on incoming requests, specifying JWT issuers, JWKS endpoints and audiences that must be satisfied. This directly fulfils the stem's requirement for JWT validation, rejecting tokens failing signature or claim checks before authorisation policies such as 'AuthorizationPolicy' evaluate the request.

forwardOriginalToken preserves the original JWT and passes it unchanged to the backend application after RequestAuthentication validates it. This satisfies scenarios where the workload itself must read the token, rather than relying solely on Istio's validation.

RequestAuthentication defines the JWT issuer, JWKS endpoint and validation rules that Istio uses to verify tokens from an external OIDC provider, rejecting requests with invalid tokens. It satisfies the stem's requirement to validate externally issued JWTs at the mesh.