Securing Workloads practice questions

ENABLED

Why it fails: ENABLED is not a valid PeerAuthentication mode; Istio defines only PERMISSIVE, STRICT and UNSET. It is tempting because ENABLED suggests turning mutual TLS on, which is what STRICT actually does by rejecting plaintext traffic, so the correct literal value is STRICT, not ENABLED.

OPTIONAL

Why it fails: OPTIONAL is not a recognised PeerAuthentication mode; the valid values are PERMISSIVE, STRICT and UNSET. It is tempting because OPTIONAL sounds like PERMISSIVE, which accepts both plaintext and mTLS traffic, but the API field requires the literal PERMISSIVE keyword rather than OPTIONAL.

DISABLED

Why it fails: DISABLED is not a valid PeerAuthentication mode; Istio accepts only PERMISSIVE, STRICT and UNSET. It is tempting because disabling mutual TLS entirely sounds like a plausible way to exempt a workload, but that is achieved by omitting the policy or using PERMISSIVE, not a DISABLED value.

Apply a PeerAuthentication resource with mode STRICT.

Why it fails: PeerAuthentication is for transport security, not JWT token validation.

Create an EnvoyFilter to parse the JWT.

Why it fails: Istio natively handles JWT via RequestAuthentication.

Set source.principals: ['prod'] in the rule.

Why it fails: principals matches workload identities in the mesh's trust domain, not namespace names, so 'prod' alone will not match. It tempts because it scopes authorisation to a source, but that source is a service account identity; restricting by namespace needs the namespaces field.

Set source.ipBlocks: ['prod'] in the rule.

Why it fails: ipBlocks matches IP address ranges in CIDR notation, not namespace labels, so 'prod' is not a valid value. It tempts because it limits traffic by source network, but that applies to external addresses; namespace-based restriction requires a namespace selector, not IP blocks.

Set source.remoteIp: ['prod'] in the rule.

Why it fails: remoteIp matches source IP addresses or CIDR ranges, not Kubernetes namespaces, so 'prod' is invalid there. It tempts because it restricts traffic by origin, but that works only for known network ranges; namespace-scoped authorisation requires the source namespace selector instead.

istioctl proxy-config rds <pod-name>

Why it fails: RDS is for route discovery, not authorization policies.

istioctl proxy-config listener <pod-name>

Why it fails: Listeners are for inbound/outbound ports, not policy logic.

istioctl proxy-config policy <pod-name>

Why it fails: This command does not exist.

VPN

Why it fails: Istio is not a VPN solution.

SSH

Why it fails: SSH is not used for data plane traffic.

IPsec

Why it fails: Istio uses TLS, not IPsec at the application layer.

accessPolicy

Why it fails: This does not exist in RequestAuthentication.

mTLSMode

Why it fails: This belongs in PeerAuthentication.

Only 'principals' is valid.

Why it fails: Both are used in different contexts.

Only 'source.principals' is valid.

Why it fails: The field name is 'principals' inside the 'source' object.

They refer to different concepts.

Why it fails: They are consistent in Istio.

Check Kubernetes logs for the API server.

Why it fails: The policy is in the sidecar, not the API server.

Restart the sidecar.

Why it fails: This is not a diagnostic step.

Update the service account.

Why it fails: Not related to policy logic.

Namespace must be 'default'

Why it fails: Works in any namespace.

Service must be exposed via NodePort

Why it fails: Not relevant to internal mTLS.

Create an EnvoyFilter to intercept and drop requests.

Why it fails: While possible, using an AuthorizationPolicy is the standard and recommended way to handle this.

Use a PeerAuthentication policy to filter based on HTTP methods.

Why it fails: PeerAuthentication does not support filtering by HTTP methods.

Set 'action: DENY', 'rules: [{to: [{operation: {methods: [POST, PUT, DELETE]}}]}]'.

Why it fails: Using DENY is less secure than an ALLOW-by-default or explicit ALLOW policy for granular control.

Modify the Istio mesh configuration to default to DENY.

Why it fails: This is not a direct configuration option in MeshConfig.

Use NetworkPolicies instead of AuthorizationPolicies.

Why it fails: NetworkPolicies are Layer 4; AuthorizationPolicies provide Layer 7 security which is better for mesh.

Use PeerAuthentication to block all traffic.

Why it fails: PeerAuthentication handles mTLS, not access control.

headers

Why it fails: Headers are checked in the 'when' block.

httpMethods

Why it fails: This belongs in the 'to' block, not the 'from' block.

jwtClaims

Why it fails: Claims are checked in the 'when' block.

destination.port

Why it fails: Port does not indicate mTLS status.

connection.mtls

Why it fails: This is not a standard attribute.

request.auth.principal

Why it fails: This is for end-user auth, not mTLS.

A PeerAuthentication resource.

Why it fails: Not strictly required for JWT, though recommended for transport security.

A Kubernetes ServiceAccount per user.

Why it fails: Users authenticate via JWT; they don't need individual ServiceAccounts.

They cannot be used with sidecar-less ambient mode.

Why it fails: PeerAuthentication is supported in ambient mode.

They validate JWT tokens.

Why it fails: RequestAuthentication validates tokens.

They support the 'DENY' action.

Why it fails: PeerAuthentication does not have an action field like AuthorizationPolicy.

Traffic will be automatically upgraded to mTLS by the destination sidecar, even if the source lacks a sidecar.

Why it fails: The destination sidecar cannot upgrade plaintext traffic to mTLS because mTLS requires both parties to present certificates. Without a sidecar, the source cannot participate in the TLS handshake. Istio's automatic mTLS only works when both source and destination have sidecars. Therefore, this option is incorrect; the destination sidecar will not magically add TLS to incoming plaintext connections.

Traffic will be allowed if the destination has PERMISSIVE mode enabled, otherwise it will be rejected.

Why it fails: While PERMISSIVE mode would allow plaintext, the scenario specifies that mutual TLS is enabled globally, which typically means STRICT mode by default. Unless a specific PeerAuthentication overrides it to PERMISSIVE, the destination will reject plaintext. This option correctly identifies that PERMISSIVE would allow it, but it does not reflect the default global mTLS behavior, which is STRICT, so the traffic would be rejected.

Traffic will be sent in plaintext, and the destination sidecar will reject it because it expects mTLS.

Why it fails: If the destination sidecar has strict mTLS enabled, it will reject plaintext traffic. However, the scenario states that mutual TLS is enabled globally, but the source 'inventory' lacks a sidecar, so it cannot originate mTLS. The destination sidecar will indeed reject plaintext, but this is not the only effect; the traffic may also be blocked at the source if the source expects to use mTLS. The key point is that the destination will reject, but the answer should capture the full behavior.

The RequestAuthentication policy is applied to the wrong namespace, so it is not enforced for the 'orders' service.

Why it fails: If the policy were in the wrong namespace, it would not select the 'orders' workload, and JWT validation would not occur at all. However, the scenario states that the RequestAuthentication policy is applied and the AuthorizationPolicy checks the audience claim. The symptom is that requests without JWT are allowed, which points to insufficient authorization rules rather than policy placement.

The RequestAuthentication policy is missing the 'audiences' field, so audience validation is skipped.

Why it fails: The audiences field in RequestAuthentication specifies which audiences are accepted when validating the JWT. If omitted, Istio does not enforce audience validation, but that would only affect tokens that are present. It would not cause requests without a JWT to be allowed. The issue is the missing authorization rule, not audience configuration.

The AuthorizationPolicy is missing the 'action: DENY' field, so it defaults to allow.

Why it fails: AuthorizationPolicy's default action is ALLOW, but if the policy has rules that do not match unauthenticated requests, those requests would not be allowed by that policy. However, if no other ALLOW policies exist, the default is deny-all when any ALLOW policy is present. The real issue is that the existing ALLOW rule does not require authentication, so requests without JWT still match it. Changing action to DENY would not fix the requirement to allow authenticated requests.

The AuthorizationPolicy uses a DENY action, but an ALLOW policy with a broader match is also present.

Why it fails: In Istio, DENY policies take precedence over ALLOW policies. If both exist, the DENY policy is evaluated first, and if it matches, the request is denied regardless of ALLOW policies. Therefore, a broader ALLOW policy would not override a DENY policy. This option is incorrect because the presence of an ALLOW policy does not make a DENY policy ineffective; rather, the DENY policy would still block traffic that matches its rules.

The AuthorizationPolicy is configured with an action of CUSTOM, but no custom authorization provider is registered.

Why it fails: The CUSTOM action requires an extension provider to be configured and registered with Istio. If no provider is registered, the policy would have no effect, but this is a less common scenario and not a typical reason for an AuthorizationPolicy to be ineffective. Most policies use ALLOW or DENY actions, which do not require external providers. This option is plausible but not one of the most common reasons for ineffectiveness.

The AuthorizationPolicy is missing a 'requestPrincipals' field, so it cannot match any requests.

Why it fails: 'requestPrincipals' is used specifically for JWT-based authentication and is not required for all AuthorizationPolicies. Many policies use other fields such as 'source', 'operation', or 'destination' to match requests. The absence of 'requestPrincipals' does not render a policy ineffective unless the policy's rules rely on it. Therefore, this is not a common reason for an AuthorizationPolicy to be ineffective in general.

Create a DestinationRule with trafficPolicy.tls.mode: DISABLE for all services in the namespace.

Why it fails: A DestinationRule with TLS mode DISABLE instructs sidecars to send plaintext traffic to the destination, which explicitly disables mTLS for outbound connections. This would undermine mTLS enforcement and is not a valid method to enforce it. It might be used for debugging but not for security compliance.

Set the 'meshConfig.enableAutoMtls' flag to false in the IstioOperator configuration.

Why it fails: Setting enableAutoMtls to false disables automatic mTLS, which is the opposite of enforcing it. This flag controls whether sidecars automatically use mTLS when no explicit DestinationRule is present. Disabling it would allow plaintext traffic, reducing security. It is not a valid way to enforce mTLS.

Check the 'istio_requests_total' metric for the 'connection_security_policy' label set to 'mutual_tls'.

Why it fails: While the 'connection_security_policy' label in Istio metrics can indicate whether a connection used mutual TLS, it is a monitoring signal, not an enforcement or verification mechanism. It does not guarantee that all traffic is mTLS; it only reports observed traffic. Relying solely on metrics is insufficient to enforce or conclusively verify mTLS enforcement.

Configure the Gateway to filter by IP.

Why it fails: Gateway IP filtering operates at the ingress edge, not on service-to-service traffic inside the mesh, so it cannot enforce the 10.0.0.0/24 source requirement for the payments workload. It is tempting because gateways do filter external client addresses, which would be correct for restricting inbound traffic entering the mesh.

Use a ServiceEntry to restrict traffic.

Why it fails: A ServiceEntry registers external hosts into the mesh registry; it does not evaluate source addresses for inbound requests to payments, so the 10.0.0.0/24 condition cannot be enforced. It is tempting because it controls traffic flow, but it would be correct for allowing egress to external services.

Create a PeerAuthentication policy with 'ipBlocks'.

Why it fails: PeerAuthentication configures mutual TLS mode and port-level settings between workloads; its schema has no ipBlocks field, so it cannot express source-range authorisation. It is tempting because it is a security policy applied to workloads, but it would be correct for enforcing strict mTLS rather than IP-based access control.