You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When deploying OPA in a CI/CD context to verify configuration or deployment resources, run Terraform policies, etc.. it isn't always ideal to run OPA in server mode. While OPA and the ecosystem provides some great options to run one-off policy checks, like opa eval or Conftest, they don't currently provide some of the management and configuration capabilities that running OPA as a standalone server does. Having CI/CD policy tasks fetch policy bundles from a centralized location, or have OPA report back the decisions it took, are both important features for OPA deployments at scale.
I suggest we introduce an --exec flag to opa run that does the following:
Runs OPA with any flags (like --config-file) normally available to opa run.
Operates with any plug-ins configured, like discovery, bundles and decision logging.
Terminates after policy evaluation (like opa eval) with exit code set depending on outcome.
While this mode of operation is going to be somewhat slower having to startup OPA and potentially pull/push data at each invocation, performance is normally not a big concern in this context.
Could be that some of the improvements for the serverless use case could be used here too, but the two use cases are fundamentally different IMO.
The text was updated successfully, but these errors were encountered:
This is just a skeleton but the basic functionality is there: run OPA
in a "one shot" mode against a set of input files and print the
results for each.
Fixesopen-policy-agent#3525
Signed-off-by: Torin Sandall <torinsandall@gmail.com>
When deploying OPA in a CI/CD context to verify configuration or deployment resources, run Terraform policies, etc.. it isn't always ideal to run OPA in server mode. While OPA and the ecosystem provides some great options to run one-off policy checks, like
opa eval
or Conftest, they don't currently provide some of the management and configuration capabilities that running OPA as a standalone server does. Having CI/CD policy tasks fetch policy bundles from a centralized location, or have OPA report back the decisions it took, are both important features for OPA deployments at scale.I suggest we introduce an
--exec
flag toopa run
that does the following:--config-file
) normally available toopa run
.opa eval
) with exit code set depending on outcome.While this mode of operation is going to be somewhat slower having to startup OPA and potentially pull/push data at each invocation, performance is normally not a big concern in this context.
Could be that some of the improvements for the serverless use case could be used here too, but the two use cases are fundamentally different IMO.
The text was updated successfully, but these errors were encountered: