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
As a user of OPA in a large organization that delegates policy authoring to different groups, I would like to be able to validate that policies packaged into bundles conform to certain standards and best practices that are specific to my organization. For example:
App repos should not be able to modify the system package except for the system/log/mask decision
App policy packages must be namespaced under package acmecorp.<app_name>
App API authorization policies must include a default allow = false rule (any other value is not allowed for the default allow rule)
One solution would be to have the build command accept an option that loads a special policy that could evaluate against the policy ASTs. The policy would be passed as set of policy ASTs as input and would be expected to produce a decision as to whether the policies are valid.
The text was updated successfully, but these errors were encountered:
Most of this is available using Regal today, and the new rule for enforcing naming conventions alone would would solve most of these requirements. For the rest of them, there's always the option to write custom rules in Rego, or to open an issue in that project for suggesting a new built-in rule. Integrating Regal at the time a bundle is built is simple, and I do believe the procedure described above is virtually identical to how we solve this in Regal, so I doubt it's worth duplicating the effort in OPA.
Closing as completed. Feel free to re-open if I missed something.
As a user of OPA in a large organization that delegates policy authoring to different groups, I would like to be able to validate that policies packaged into bundles conform to certain standards and best practices that are specific to my organization. For example:
package acmecorp.<app_name>
default allow = false
rule (any other value is not allowed for the default allow rule)One solution would be to have the
build
command accept an option that loads a special policy that could evaluate against the policy ASTs. The policy would be passed as set of policy ASTs as input and would be expected to produce a decision as to whether the policies are valid.The text was updated successfully, but these errors were encountered: