Skill Guide
The practice of defining, enforcing, and auditing granular network communication rules and encryption/authentication policies between services within a distributed microservices architecture (service mesh) to enforce zero-trust principles.
Scenario
You have a 'web', 'api', and 'database' pod in a single namespace. The web pod should only talk to the api pod; the api pod should only talk to the database pod; no direct web-to-database access is allowed.
Scenario
Extend the previous project by deploying Istio. Enforce strict mTLS for all communication in the namespace. Then, add a policy that only allows the 'api' service's ServiceAccount to access a specific '/data' endpoint on the 'database' service.
Scenario
Your organization requires all network and authorization policies to be version-controlled, peer-reviewed, and automatically deployed across dev, staging, and prod clusters. The system must validate policies for syntax and security best practices (e.g., no overly permissive rules) before deployment.
Use Kubernetes NetworkPolicy for basic pod-to-pod filtering. Adopt Istio or Cilium as a full service mesh for L7 policies, mTLS, and observability. Envoy is the data plane sidecar proxy. OPA/Gatekeeper is used to enforce custom policy constraints at the admission control level before resources are created.
Kiali provides a visual map of service communication and policy enforcement. Use Prometheus to scrape metrics like `istio_requests_total` to monitor policy effectiveness. For deep debugging, you can run `tcpdump` within a sidecar container or use Envoy's admin interface.
Use ZTA principles (microsegmentation, least privilege) as the core design philosophy. NIST SP 800-207 provides a reference architecture. The MITRE ATT&CK Cloud Matrix helps map potential adversary tactics (like lateral movement via service-to-service calls) to the defensive controls you are implementing.
Answer Strategy
The interviewer is testing your understanding of migration risks and your structured operational methodology. Do not just say 'change the setting'. Sample Answer: 'My plan would be phased. First, I would audit all services in the mesh using Kiali or traffic logs to identify any non-meshed services or external clients that lack sidecars, as these will break under STRICT mode. Second, I would communicate the change and required client-side modifications (e.g., installing sidecars) to application teams. Third, I would change the PeerAuthentication policy to STRICT but do it during a low-traffic maintenance window. The key risk is breaking communication for any service not properly integrated with the mesh, which could cause a total outage. I would have the rollback procedure (reverting to PERMISSIVE) ready and be prepared to execute it based on alerting from metrics like increased 5xx errors.'
Answer Strategy
This tests your hands-on debugging process and knowledge of the service mesh's observability tools. Sample Answer: 'First, I'd verify the service identity. I would check the `source.principal` field in the Envoy access logs of the destination service's sidecar to confirm the calling service's identity matches what's expected in the AuthorizationPolicy. Second, I would use `istioctl analyze` and `istioctl proxy-config routes` to inspect the pushed configuration to the sidecar, checking for misapplied or missing AuthorizationPolicy rules. Third, I would examine the AuthorizationPolicy resource itself for logical errors-such as an incorrect namespace selector, a missing `from.source` block, or an overly restrictive `to.operation` block (wrong HTTP path or method). Finally, I would check the service's `ServiceEntry` if it's calling an external service, as that requires explicit configuration.'
1 career found
Try a different search term.