Cloud Native Operations

English

한국어

English

한국어

Appearance

Policies Quiz ​

This quiz tests your understanding of Kubernetes policy concepts including resource quotas, limit ranges, pod security policies, and network policies.

Multiple Choice Questions ​

  1. What is the main purpose of ResourceQuota in Kubernetes?
    • A) Limiting pod CPU and memory usage
    • B) Limiting resource creation within a namespace
    • C) Monitoring cluster-wide resource usage
    • D) Managing node resource allocation
Show Answer

Answer: B) Limiting resource creation within a namespace

Explanation: ResourceQuota limits the total amount of resources that can be created within a namespace. This includes not only computing resources like CPU and memory but also the number of objects such as pods, services, and configmaps. Using ResourceQuota prevents one team from monopolizing all cluster resources.

  1. What is the main function of LimitRange?
    • A) Limiting total namespace resource usage
    • B) Setting default resource requests and limits for individual containers
    • C) Distributing resources between cluster nodes
    • D) Restricting network communication between pods
Show Answer

Answer: B) Setting default resource requests and limits for individual containers

Explanation: LimitRange defines resource constraints for pods or containers within a namespace. This allows setting default resource requests and limits, or enforcing minimum/maximum resource usage. LimitRange applies to individual resources, while ResourceQuota applies to the entire namespace.

  1. After PodSecurityPolicy (PSP) was removed in Kubernetes v1.25, what mechanism replaced it?
    • A) PodSecurityStandards
    • B) PodSecurityContext
    • C) PodSecurityAdmission
    • D) SecurityContextConstraints
Show Answer

Answer: C) PodSecurityAdmission

Explanation: PodSecurityPolicy (PSP) was removed in Kubernetes v1.25, and PodSecurityAdmission replaced it. This is a built-in admission controller based on Pod Security Standards, providing three policy levels: Privileged, Baseline, and Restricted. PodSecurityContext is used to configure security settings at the pod level, and SecurityContextConstraints is a similar mechanism used in OpenShift.

  1. What CANNOT be done using NetworkPolicy?
    • A) Restricting traffic to pods from a specific namespace only
    • B) Restricting traffic to a specific IP CIDR range only
    • C) Restricting traffic to a specific port only
    • D) Inspecting payload content of specific protocols
Show Answer

Answer: D) Inspecting payload content of specific protocols

Explanation: NetworkPolicy provides L3/L4 level firewall policies that control communication between pods. This allows restricting traffic based on specific namespaces, labels, IP CIDR ranges, ports, etc. However, NetworkPolicy cannot perform L7 level inspection (e.g., HTTP headers, payload content). For such functionality, you need to use a service mesh (e.g., Istio) or API gateway.

  1. What is the main purpose of RBAC (Role-Based Access Control) in Kubernetes?
    • A) Controlling network communication between pods
    • B) Managing permissions for users and service accounts
    • C) Limiting resource usage
    • D) Setting pod scheduling policies
Show Answer

Answer: B) Managing permissions for users and service accounts

Explanation: RBAC (Role-Based Access Control) is a mechanism for controlling access to the Kubernetes API. Through this, you can define what operations users, groups, or service accounts can perform within the cluster. RBAC manages permissions using resources such as Role, ClusterRole, RoleBinding, and ClusterRoleBinding.

  1. Which is the most restrictive of the three policy levels in Pod Security Standards?
    • A) Privileged
    • B) Baseline
    • C) Restricted
    • D) Enforced
Show Answer

Answer: C) Restricted

Explanation: Pod Security Standards define three policy levels:

  • Privileged: No restrictions, all privileges allowed
  • Baseline: Prevents known privilege escalation paths
  • Restricted: Most restrictive policy with enhanced security settings applied

The Restricted policy is the most restrictive, following the principle of least privilege and applying security best practices. This policy prohibits privileged containers, host namespace sharing, host path mounts, and more.

  1. What is the role of AdmissionController in Kubernetes?
    • A) User authentication
    • B) Monitoring resource usage
    • C) Validating and modifying API requests
    • D) Pod scheduling
Show Answer

Answer: C) Validating and modifying API requests

Explanation: AdmissionController is a plugin that intercepts and validates or modifies requests to the Kubernetes API server after they pass authentication and authorization, but before objects are stored in persistent storage. This allows cluster administrators to apply policies for resource creation and modification. For example, PodSecurityAdmission, ResourceQuota, and LimitRanger are implemented as AdmissionControllers.

  1. What is the main function of OPA (Open Policy Agent) Gatekeeper in Kubernetes?
    • A) Cluster monitoring and logging
    • B) Policy-based resource management and validation
    • C) Auto scaling
    • D) Service mesh management
Show Answer

Answer: B) Policy-based resource management and validation

Explanation: OPA Gatekeeper is an extensible solution for applying policies to Kubernetes clusters. It's based on OPA (Open Policy Agent) and uses CustomResourceDefinitions (CRDs) to define and apply policies. Gatekeeper operates as an AdmissionWebhook to verify that resources created or modified in the cluster comply with defined policies. This enables applying various policies such as security policies, resource limits, and naming conventions.

  1. A namespace has quotas for CPU/memory requests and limits and no admission defaults. What happens to a Pod whose containers specify none of these resources?
    • A) Pod is created with default resource requests and limits
    • B) Pod creation is rejected
    • C) Pod is created but not scheduled
    • D) Pod is created and can use unlimited resources
Show Answer

Answer: B) Pod creation is rejected

Explanation: When ResourceQuota is applied to a namespace and quotas are set for computing resources like CPU and memory, Pods must have the resource fields needed by that quota after defaulting. If the required values remain missing after admission defaulting, creation is rejected. A LimitRange can fill defaults; an object-count-only quota does not require CPU/memory fields. This is to accurately track and limit resource usage in namespaces with quotas applied.

  1. What is the main purpose of PriorityClass in Kubernetes?
    • A) Defining pod scheduling priority
    • B) Setting namespace resource allocation priority
    • C) Determining API request processing priority
    • D) Setting node importance levels
Show Answer

Answer: A) Defining pod scheduling priority

Explanation: PriorityClass defines the scheduling priority of pods. When resources are scarce, higher-priority pods are scheduled before lower-priority ones, and can preempt lower-priority pods if necessary.

Short Answer Questions ​

  1. Explain the main differences between ResourceQuota and LimitRange.
Show Answer

Answer: ResourceQuota limits resource usage for the entire namespace, while LimitRange sets resource constraints for individual containers or pods within a namespace.

Key differences:

  1. Scope: ResourceQuota applies to the entire namespace, LimitRange applies to individual resources (pods, containers, etc.).
  2. Purpose: ResourceQuota limits total namespace resource usage, while LimitRange controls individual resource usage through default settings, minimum/maximum limits, etc.
  3. Enforcement: When ResourceQuota is set, resource creation exceeding the quota is rejected. LimitRange applies defaults when resources are created or rejects if limits are exceeded.
  4. Resource types: ResourceQuota can limit not only CPU and memory but also object counts like pods, services, and PVCs. LimitRange primarily focuses on computing resources like CPU, memory, and storage.
  1. Explain the three policy levels (Privileged, Baseline, Restricted) of Pod Security Standards and their characteristics.
Show Answer

Answer: Pod Security Standards define three policy levels for pod security settings:

  1. Privileged:

    • Most open policy with almost no restrictions.
    • Allows all privileged operations.
    • Can use host namespaces, host ports, privileged containers, etc.
    • Suitable for development and administrative work, but poses significant security risks in production.

  2. Baseline:

    • Mid-level policy that prevents known privilege escalation paths.
    • Provides a baseline level of security suitable for most workloads.
    • Restricts privileged containers and host namespace usage.
    • HostPath volumes are forbidden by Baseline too; Restricted adds requirements such as non-root execution, seccomp, and capability restrictions.

  3. Restricted:

    • Most restrictive policy with enhanced security settings.
    • Follows the principle of least privilege and enforces security best practices.
    • Prohibits privileged containers, host namespaces, host path mounts, and privilege escalation.
    • Forces containers to run as non-root users.
    • Suitable for security-critical production workloads.
  1. Explain how to restrict pods in a specific namespace to communicate only with specific pods in another namespace using NetworkPolicy.
Show Answer

Answer: To restrict pods in a specific namespace to communicate only with specific pods in another namespace using NetworkPolicy:

  1. Apply NetworkPolicy to source namespace:
yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-communication
  namespace: source-namespace  # Source namespace
spec:
  podSelector: {}  # Apply to all pods
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: destination-namespace  # Destination namespace label
      podSelector:
        matchLabels:
          app: specific-app  # Destination pod label
  1. Apply NetworkPolicy to destination namespace:
yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-specific-namespace
  namespace: destination-namespace  # Destination namespace
spec:
  podSelector:
    matchLabels:
      app: specific-app  # Destination pod label
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: source-namespace  # Source namespace label

For this method to work, namespaces must have appropriate labels:

bash
kubectl label namespace source-namespace name=source-namespace
kubectl label namespace destination-namespace name=destination-namespace

These policies isolate the selected directions only. Other NetworkPolicies add their allowed traffic; they cannot narrow a broader allow policy. Add DNS egress separately when names are used, and test both source and destination rules.

  1. Explain three policy examples that can be implemented using OPA Gatekeeper in Kubernetes.
Show Answer

Answer: Policy examples that can be implemented using OPA Gatekeeper:

Install each matching ConstraintTemplate from the official Gatekeeper library first. These kinds are generated by templates, not built-in APIs; the library K8sRequiredLabels schema differs from the chapter's simplified K8sRequiredLabelKeys.

  1. Image Registry Restriction:

    • Policy that forces images to only be pulled from approved registries
    • Example: Allow only company internal registries or specific trusted public registries
    yaml
    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allowed-repos
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    repos:
      - "docker.io/company/"
      - "gcr.io/trusted-project/"

  2. Enforce Resource Requests and Limits:

    • Policy that forces all containers to have resource requests and limits set
    • Prevents resource exhaustion and ensures proper resource allocation
    yaml
    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredResources
metadata:
  name: container-must-have-limits-and-requests
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    limits:
      - cpu
      - memory
    requests:
      - cpu
      - memory

  3. Prevent Privileged Containers:

    • Policy that prohibits running privileged containers
    • Reduces security risks and ensures container isolation
    yaml
    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: prevent-privileged-containers
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

  4. Restrict host filesystem access (requires the library's matching template):

    yaml
    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPHostFilesystem
metadata:
  name: prevent-host-filesystem-mount
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
  parameters:
    allowedHostPaths: []

  5. Require labels with constrained values:

    yaml
    apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-team-label
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod", "Service"]
    - apiGroups: ["apps"]
      kinds: ["Deployment"]
  parameters:
    labels:
    - key: team
      allowedRegex: "^(frontend|backend|infra)$"
    - key: environment
      allowedRegex: "^(dev|staging|prod)$"

(Only three of the above need to be explained)

  1. Explain how to ensure availability of important workloads using PriorityClass in Kubernetes.
Show Answer

Answer: How to ensure availability of important workloads using PriorityClass:

  1. Define PriorityClass:

    • Create PriorityClasses with various priority levels based on importance
    yaml
    apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000  # Higher value means higher priority
globalDefault: false
description: "This priority class should be used for critical production workloads."

  2. Assign PriorityClass to important workloads:

    • Add PriorityClass reference to important pods
    yaml
    apiVersion: v1
kind: Pod
metadata:
  name: critical-service
spec:
  priorityClassName: high-priority
  containers:
  - name: app
    image: critical-service:latest

  3. Leverage Preemption:

    • When resources are scarce, higher priority pods can preempt (evict) lower priority pods and be scheduled
    • This improves scheduling preference, but cannot guarantee placement if constraints or available capacity still prevent it

  4. Consider System Priority Classes:

    • Kubernetes provides system priority classes like system-cluster-critical (2000000000) and system-node-critical (2000001000)
    • User-defined PriorityClass values must be at most 1,000,000,000; higher values are reserved for system classes

  5. Design Priority Hierarchy:

    • Define multiple priority levels based on workload importance
    • Example: Production services (900000), Internal tools (500000), Development/Test (100000)

Hands-on Questions ​

  1. Create a ResourceQuota that meets the following requirements:
    • Namespace: team-a
    • Maximum 10 pods
    • Maximum 5 services
    • Total CPU requests: 4 cores
    • Total memory requests: 8Gi
Show Answer

Answer:

yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    pods: "10"
    services: "5"
    requests.cpu: "4"
    requests.memory: 8Gi

How to apply:

bash
# Create namespace
kubectl create namespace team-a

# Apply ResourceQuota
kubectl apply -f team-a-quota.yaml

Check ResourceQuota status:

bash
kubectl describe resourcequota team-a-quota -n team-a
  1. Create a LimitRange that meets the following requirements:
    • Namespace: team-b
    • Container default request: CPU 100m, Memory 256Mi
    • Container default limit: CPU 200m, Memory 512Mi
    • Container maximum limit: CPU 1 core, Memory 2Gi
Show Answer

Answer:

yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: team-b-limits
  namespace: team-b
spec:
  limits:
  - default:
      cpu: 200m
      memory: 512Mi
    defaultRequest:
      cpu: 100m
      memory: 256Mi
    max:
      cpu: "1"
      memory: 2Gi
    type: Container

How to apply:

bash
# Create namespace
kubectl create namespace team-b

# Apply LimitRange
kubectl apply -f team-b-limits.yaml

Check LimitRange status:

bash
kubectl describe limitrange team-b-limits -n team-b
  1. Create a NetworkPolicy that meets the following requirements:
    • Namespace: web
    • Pods with app label 'frontend' can only communicate with pods with app label 'backend'
    • Backend pods allow communication only on port 8080
Show Answer

Answer:

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-to-backend-only
  namespace: web
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend-only
  namespace: web
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

How to apply:

bash
# Create namespace
kubectl create namespace web

# Apply NetworkPolicy
kubectl apply -f web-network-policies.yaml

Check NetworkPolicy status:

bash
kubectl describe networkpolicy -n web
  1. Create a PriorityClass and a pod using it with the following requirements:
    • PriorityClass name: high-priority
    • Priority value: 100000
    • Description: "For critical production workloads"
    • Pod name: critical-app
    • Image: nginx
Show Answer

Answer:

yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 100000
globalDefault: false
description: "For critical production workloads"
---
apiVersion: v1
kind: Pod
metadata:
  name: critical-app
spec:
  priorityClassName: high-priority
  containers:
  - name: nginx
    image: nginx

How to apply:

bash
kubectl apply -f high-priority-pod.yaml

Check PriorityClass and pod status:

bash
kubectl get priorityclass high-priority
kubectl get pod critical-app
  1. Apply the following Pod Security settings:
    • Namespace: restricted-ns
    • Mode: enforce
    • Level: restricted
Show Answer

Answer:

In Kubernetes 1.25 and above, you can apply Pod Security Standards by adding labels to the namespace:

yaml
apiVersion: v1
kind: Namespace
metadata:
  name: restricted-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

How to apply:

bash
kubectl apply -f restricted-namespace.yaml

Or add labels to an existing namespace:

bash
kubectl create namespace restricted-ns
kubectl label namespace restricted-ns \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

Advanced Topics ​

  1. Explain the differences between OPA Gatekeeper and Kyverno in Kubernetes and their respective pros and cons.
Show Answer

Answer:

OPA Gatekeeper vs Kyverno Comparison:

  1. Architecture and Approach:

    • OPA Gatekeeper: Based on Open Policy Agent (OPA), uses the Rego policy language. Defines policies using two CRDs: ConstraintTemplate and Constraint.
    • Kyverno: Uses its own policy engine, providing YAML/JSON-based policy definitions. Provides multiple policy kinds, including Policy/ClusterPolicy and dedicated cleanup/CEL policy APIs depending on version.

  2. Policy Language:

    • OPA Gatekeeper: Uses Rego language, powerful but has a steep learning curve.
    • Kyverno: Defines policies using YAML syntax similar to Kubernetes resources, more familiar to Kubernetes users.

  3. Features:

    • OPA Gatekeeper:
      • Powerful policy language for expressing complex policies
      • Can integrate data sources for external data-based decisions
      • Supports policy libraries and reusable templates
    • Kyverno:
      • Built-in resource creation, modification, and validation features
      • Image verification and modification features
      • Can automatically create other resources when resources are created
      • Policy exception handling features

  4. Pros:

    • OPA Gatekeeper:
      • Established Rego policy ecosystem and reusable templates
      • Better suited for complex policy expression
      • Extensive documentation and examples for various use cases
      • OPA ecosystem usable outside of Kubernetes
    • Kyverno:
      • Easier learning curve with familiar YAML syntax
      • No separate policy language learning required
      • Built-in resource creation and modification features
      • Simpler setup and configuration

  5. Cons:

    • OPA Gatekeeper:
      • Requires learning Rego language
      • Complex setup and configuration
      • Additional configuration needed for resource modification
    • Kyverno:
      • Requires version-specific CRD and feature compatibility checks
      • May have limitations for very complex policy expression
      • Benchmark representative policies and admission load; there is no universal engine performance ranking

  6. Selection Criteria:

    • Choose OPA Gatekeeper when:
      • Complex policy logic is needed
      • Already using OPA or familiar with Rego
      • Need consistent policy application across various systems
    • Choose Kyverno when:
      • Quick start and easy learning curve are important
      • Team is familiar with Kubernetes resource syntax
      • Resource creation and modification features are needed
      • Kubernetes-native mutation, generation, verification, or validation fits the policy requirements
  1. Explain the main differences between Pod Security Admission and the previous PodSecurityPolicy (PSP) in Kubernetes.
Show Answer

Answer:

Pod Security Admission vs PodSecurityPolicy (PSP) Comparison:

  1. Implementation:

    • PodSecurityPolicy: Implemented as built-in API resource (not a CRD), applied through admission controller.
    • Pod Security Admission: Implemented as built-in admission controller, configured through namespace labels.

  2. Configuration Method:

    • PodSecurityPolicy: Cluster admin must create PSP resources and bind them to users/service accounts through RBAC.
    • Pod Security Admission: Apply by adding labels to namespaces specifying enforcement level (enforce, audit, warn) and policy level (privileged, baseline, restricted).

  3. Policy Granularity:

    • PodSecurityPolicy: Very fine-grained control possible, can individually configure various security context settings.
    • Pod Security Admission: Only provides three predefined policy levels (privileged, baseline, restricted), cannot individually adjust detailed settings.

  4. Ease of Use:

    • PodSecurityPolicy: Complex setup requiring RBAC bindings, configuration errors are common.
    • Pod Security Admission: Applied with simple namespace labeling, much easier to use.

  5. Scope:

    • PodSecurityPolicy: Applies to entire cluster or specific users/service accounts.
    • Pod Security Admission: Applies per namespace.

  6. Modes:

    • PodSecurityPolicy: Binary approach of apply or not apply.
    • Pod Security Admission: Provides three modes (enforce, audit, warn) for gradual application.
      • enforce: Reject pod creation on violation
      • audit: Log violations to audit log
      • warn: Display warning message on violation

  7. Migration and Support:

    • PodSecurityPolicy: Removed in Kubernetes v1.25.
    • Pod Security Admission: Available as beta since Kubernetes v1.23, fully replaced PSP in v1.25.

  8. Extensibility:

    • PodSecurityPolicy: High extensibility through custom settings.
    • Pod Security Admission: Limited extensibility, additional tools like OPA Gatekeeper or Kyverno may be needed for finer control.
  1. Explain how an external authorization webhook can supplement Kubernetes RBAC, and why ordering matters.
Show Answer

Answer:

For a self-managed API server, configure a TLS-authenticated webhook using a kubeconfig that supplies its endpoint, CA, client certificate, and key. A flag-based example is:

text
--authorization-mode=Node,RBAC,Webhook
--authorization-webhook-config-file=/path/to/webhook-config.yaml
--authorization-webhook-version=v1

The webhook receives an authorization.k8s.io/v1 SubjectAccessReview containing the authenticated user/groups and request attributes, and returns a SubjectAccessReview status such as allowed: true or an explicit denial. It must validate transport credentials, handle errors/timeouts deliberately, and avoid logging bearer tokens or confidential request data.

The authorizer chain stops at the first allow or deny. In Node,RBAC,Webhook, an RBAC allow skips the webhook. A later webhook cannot veto that permission. Mandatory external denial policies need an appropriate ordering/failure policy or suitable admission enforcement. Structured AuthorizationConfiguration supports additional webhook controls. EKS does not expose arbitrary API-server authorization flags.

An OPA adapter can evaluate the review with Rego. This OPA 1.x example uses current rule syntax:

rego
package kubernetes.authz

default allow := false

allow if {
    input.spec.resourceAttributes.namespace == "default"
    input.spec.resourceAttributes.resource == "deployments"
    input.spec.resourceAttributes.verb == "get"
    input.spec.user == "jane"
    "developers" in input.spec.groups
}

Deploy a compatible OPA version, load the policy bundle, and implement an adapter that submits the review as OPA input and maps the result to SubjectAccessReview status. A bare OPA Deployment is not a complete authorization webhook. Centralized policy, external attributes, and auditability are benefits; availability, latency, cache TTLs, and denial behavior must be tested.

  1. Design multi-tenant network isolation using NetworkPolicy.
Show Answer

Answer:

Start with a default-deny ingress/egress policy in each tenant namespace. Then choose either broad intra-tenant communication or fine-grained role-based rules. Because policies are additive, a broad allow-same-namespace policy defeats narrower role restrictions if both are applied.

For the broad intra-tenant option, allow both directions; ingress alone does not undo the default egress deny:

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
  ingress:
  - from:
    - podSelector: {}
  egress:
  - to:
    - podSelector: {}

For finer isolation, select labels such as role: backend or tier: web instead. Expose only selected APIs to other tenants by combining a namespace selector and Pod selector in the same peer, with explicit destination ports. Use the built-in kubernetes.io/metadata.name namespace label or maintain a protected tenant label convention.

Shared-service access needs matching source egress and destination ingress. Allowing tenants to reach Prometheus on 9090 exposes its API/UI; it does not authorize Prometheus to scrape tenant Pods. Scraping needs the reverse traffic path. Restrict external egress with appropriate IP ranges and TCP ports, or an implementation supporting domain policies when IPs are unsuitable.

DNS egress commonly needs the following rule (adjust for NodeLocal DNS or different labels):

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: tenant-a
spec:
  podSelector: {}
  policyTypes: [Egress]
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Use a policy-enforcing CNI, protect namespace/Pod label changes with RBAC and admission rules, version policies, and test allowed and denied flows. Standard NetworkPolicy does not provide L7 authentication and has documented node/host-network limitations.

  1. Explain a resource-management strategy combining ResourceQuota and LimitRange.
Show Answer

Answer:

  • At cluster level, plan node capacity, autoscaling, and workload isolation. At namespace level, constrain requested/limited compute, storage, and object counts. At workload level, set measured resource requests and Pod priority.
  • Use requests.storage and <class>.storageclass.storage.k8s.io/requests.storage for PVC allocation. For arbitrary object counts use keys such as count/deployments.apps and count/statefulsets.apps; bare deployments.apps is not the object-count syntax.
  • Apply a separate PriorityClass-scoped quota with scopeSelector and hard.pods for each class. PriorityClass belongs to Pods, not directly to namespaces.
  • Use Container LimitRange entries for defaults and min/max validation. Pod entries constrain aggregate resources, and PVC entries constrain storage requests; neither supplies defaults.
yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
  namespace: team-a
spec:
  hard:
    pods: "50"
    services: "10"
    services.loadbalancers: "2"
    services.nodeports: "5"
    secrets: "20"
    configmaps: "20"
    count/deployments.apps: "10"
    count/statefulsets.apps: "5"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: storage-limits
  namespace: team-a
spec:
  limits:
  - type: PersistentVolumeClaim
    min:
      storage: 1Gi
    max:
      storage: 100Gi

ResourceQuota and LimitRange have no built-in audit-only mode: evaluate changes in test namespaces and through dry-run where applicable. Monitor quota allocation separately from actual usage, alert before limits, and adjust requests based on measurements. Dynamic quota changes, borrowing, shared pools, and chargeback need additional controllers/automation; native hard quotas do not permit temporary overages. Quotas limit admission rather than guarantee workload performance.