Quiz: Open Policy Agent

← Back to quiz index

6 questions

L1 (3 questions)

1. What is Open Policy Agent (OPA) and how does it decouple policy from application code?

Show answer

OPA is a general-purpose policy engine that evaluates policies written in Rego (a declarative query language). Instead of embedding authorization logic in each service's code, services send a structured input (JSON) to OPA and receive a policy decision (allow/deny + reasons). This decouples policy from code: security teams write policies, developers write features. OPA can be deployed as a sidecar, library, or centralized service. Used for: Kubernetes admission control (Gatekeeper), API authorization, Terraform plan validation, and data filtering.

2. What is the Rego language and how does it differ from imperative programming languages?

Show answer

Rego is a declarative query language designed for policy. Instead of writing step-by-step logic (if/else chains), you write rules that declare what is true. Rego evaluates all rules and returns the result. Key concepts: rules (name = value { conditions }), partial rules (set/object builders), comprehensions (set/array/object), unification (= for both assignment and comparison). It is closer to SQL or Prolog than Python. Common mistake: trying to write imperative code — instead, think in terms of 'what conditions must be true for this result to hold.'

3. What is the difference between running OPA as a sidecar vs a centralized service?

Show answer

Sidecar: OPA runs alongside each service (in the same pod or as a daemon). Advantages: low latency (localhost call), no network dependency, scales with the service. Disadvantages: more resource usage, policy distribution needed to all instances. Centralized: single OPA service that all applications query. Advantages: easier to manage and monitor, single policy source. Disadvantages: network latency, single point of failure, must handle high throughput. For Kubernetes admission control, Gatekeeper runs centrally as a webhook. For service authorization, sidecar is preferred for latency-sensitive paths.

L2 (3 questions)

1. How does OPA Gatekeeper enforce policies in Kubernetes and what is the difference between a ConstraintTemplate and a Constraint?

Show answer

Gatekeeper runs as a Kubernetes admission webhook. ConstraintTemplate defines the policy logic in Rego (e.g., 'containers must not run as root') and declares the parameters the policy accepts. Constraint instantiates a template with specific parameters and scope (which namespaces, resource kinds). Example: ConstraintTemplate 'K8sAllowedRepos' has Rego checking image registries. Constraint 'allowed-repos' applies it to Pods in namespace 'production' with parameter registries: ['gcr.io/myproject']. This separation lets platform teams write templates and cluster admins apply constraints.

2. How do you test OPA policies and integrate them into a CI/CD pipeline?

Show answer

1. Write unit tests in Rego: test_ prefixed rules with mock input data. Run with 'opa test . -v'.
2. Use opa eval with sample inputs to verify behavior locally.
3. In CI: run 'opa test' on every policy change, 'opa check --strict' for syntax validation, and 'opa fmt --diff' for formatting.
4. For Gatekeeper: use gator test to validate constraints against sample resources.
5. Integration test: deploy to a staging cluster with audit mode (dryrun) before enforce.
6. Version policies in git alongside the infrastructure code they protect.

3. How do you manage policy data (external data OPA needs for decisions) and keep it fresh?

Show answer

OPA decisions often need external data (user roles, resource ownership, IP allowlists). Approaches:
1. Bundle API: OPA periodically fetches a data bundle (JSON + policies) from an HTTP server. Configure bundle service with polling interval.
2. Push via API: POST data to OPA's /v1/data endpoint.
3. Overload input: caller includes all needed data in the decision request input. Best practice: use bundles for data that changes infrequently (roles, config), push for real-time data (revocation lists), input for request-specific data (user context). Monitor bundle download failures and staleness.