Container and Kubernetes Security Questions

Brief approach
Provide least-privilege Role that grants read-only to secrets in a namespace and a separate Role for creating CustomMetrics CRs (assumed group/verbs). Bind both to the serviceAccount.

Manifests

# Namespace-scoped ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: metrics-reader
  namespace: app-namespace

# Read-only Role for secrets
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secrets-read-only
  namespace: app-namespace
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]

# Role to create custom metrics (adjust apiGroup/resource to CRD)
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: custommetrics-create
  namespace: app-namespace
rules:
- apiGroups: ["custom.metrics.k8s.io"]   # replace with actual CRD group
  resources: ["custommetrics"]            # replace with actual CRD
  verbs: ["create", "get", "list", "watch"]

# RoleBinding that attaches both Roles to the SA
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: metrics-reader-binding
  namespace: app-namespace
subjects:
- kind: ServiceAccount
  name: metrics-reader
  namespace: app-namespace
roleRef:
  kind: Role
  name: secrets-read-only
  apiGroup: rbac.authorization.k8s.io

# Additional RoleBinding for custom metrics Role
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: custommetrics-binding
  namespace: app-namespace
subjects:
- kind: ServiceAccount
  name: metrics-reader
  namespace: app-namespace
roleRef:
  kind: Role
  name: custommetrics-create
  apiGroup: rbac.authorization.k8s.io

Auditing for overprivileged SAs

• Query RBAC bindings: kubectl get rolebindings, clusterrolebindings and map subjects to roles/clusterroles.
• Evaluate effective permissions: use rbac-lookup or kube-psp-advisor; run "kubectl auth can-i --as=system:serviceaccount:namespace:name --list".
• Search for wildcard verbs/resources in ClusterRoles/ClusterRoleBindings.
• Use kube-bench, KubeHunter, or custom scripts that resolve aggregated ClusterRoles and CRDs to enumerate privileges.

Reduce privilege escalation risks

• Network segmentation: enforce NetworkPolicies so compromised pod can’t reach control-plane or metadata endpoints.
• Disable in-cluster metadata access or use projected tokens with audience and expiration (bound-service-account-token).
• Use PodSecurityPolicies / PodSecurity admission to disallow hostPath, privileged, hostNetwork, and escalatable capabilities.
• Limit container capabilities (drop ALL, add minimal).
• Use read-only root filesystem and seccomp/AppArmor profiles.
• Rotate and scope service account tokens; prefer short-lived projected tokens.
• Audit & alert on abnormal RBAC changes and pod exec/port-forward events.

Approach overview
I assess microservice communications by validating authentication, confidentiality, authorization, network controls, and certificate hygiene — in that order — using automated scans, manual review, and runtime tests.

Key areas to evaluate

• mTLS: Verify mutual TLS enforced between pods/services; confirm client and server cert validation, cipher suites, TLS versions, and perfect forward secrecy. Test by attempting connections with invalid/expired certs and TLS downgrade attempts.
• Service mesh considerations: If using Istio/Linkerd/Consul, check mesh-wide mTLS vs. per-namespace, sidecar injection scope, control plane RBAC, and mesh policy enforcement (destination rules, peer authentication). Validate fallback behaviors when sidecars are absent.
• Identity & authorization: Review Kubernetes ServiceAccounts mapped to workloads, use of federated identities (SPIFFE/SPIRE), and short-lived service identity tokens. Test least-privilege RBAC, token audience/exp claims, and impersonation attempts.
• NetworkPolicies: Confirm egress/ingress policies restrict pod-to-pod flows; simulate lateral movement attempts, and ensure default deny where appropriate.
• Ingress/Egress controls: Validate API gateway/TLS termination points, WAF rules, and egress proxies for outbound filtering and DNS/HTTP allowlists.
• Certificate lifecycle management: Assess automated issuance/rotation (cert-manager/SPIRE), CA trust boundaries, revocation processes (CRL/OCSP), and monitoring/alerting for expiry.

Prioritized testing checklist

1. Ensure mTLS enforced cluster/namespace-wide; attempt invalid-cert connections.
2. Confirm service identity binds to SA and SPIFFE; test token replay/impersonation.
3. Validate RBAC least privilege for control plane and service accounts.
4. Test NetworkPolicies: default deny, and allow-only-needed paths.
5. Inspect sidecar configs: health, restart behavior, bypass risks.
6. Verify ingress TLS termination, HTTP->HTTPS redirects, and WAF rules.
7. Confirm egress filtering and DNS protection.
8. Check cert rotation automation, expiry alerts, and revocation paths.
9. Run chaos tests: simulate control-plane failure and certificate expiry to observe fallback.
10. Review logging/observability for mTLS failures and audit trails.

Notes on tooling & metrics
Use kube-bench, conftest, Istioctl/Linkerd CLI, cert-manager audits, tls-scan, and custom e2e tests. Measure: percent of encrypted flows, token lifetime, policy coverage, and mean time to rotate/revoke certificates.