Feature/sentinel policy

[Ilansos]

Summary
This PR adds end-to-end Sentinel policy support to OTF, including policy set management, policy evaluation during runs, database support, API/UI flows, and run lifecycle updates to surface policy checks and Sentinel execution results.

What Changed

• Added a new internal/policy service layer for policy sets, policies, evaluation, storage, and API handling.
• Added database migrations for:
  • Sentinel policy support
  • a dedicated Sentinel run phase
  • policy-check run statuses
  • VCS-backed policy set sources
  • policy modules
• Extended run execution flow to include Sentinel policy evaluation between plan and apply.
• Added policy-aware run status and phase handling, including policy check reporting and Sentinel logs.
• Added UI pages and routes for:
  • listing policy sets
  • creating manual policy sets
  • connecting VCS-backed policy sets
  • syncing policy sets from VCS
  • creating, updating, and deleting policies
  • downloading workspace Sentinel mocks
• Updated the run UI to display:
  • Sentinel phase status and timing
  • Sentinel logs
  • policy check results for a run
• Added authorization and resource-kind updates needed for policy management.
• Wired the feature into the current refactored UI/daemon structure in this fork so it works with the newer codebase instead of reverting newer work.

Implementation Notes

• The original feature branch was based on an older repo structure.
• During transfer to the fork, the feature was merged into the newer handler/UI architecture already present in this repo.
• A follow-up compatibility commit wires policy checks into the refactored internal/run/ui flow.

[Ilansos]

@leg100 Hi, I would like for your help. I'm having issues with the tests in the build workflow, seems to be a problem with the TLS certificate in the test. Currently I'm not able to resolve this issue by myself

[leg100]

@Ilansos The 2026/03/31 19:07:35 http: TLS handshake error from 127.0.0.1:59546: remote error: tls: unknown certificate errors can safely be ignored. They're not the reason your tests are failling. I think you just need to revert your last few commits and it'll start working again. I posted a fix earlier for broken tests:

5cbffc3

[mlanth]

A few notes on the current implementation; feel free to take them in context, especially since policy support isn’t something I’m actively using right now.

Given the spirit of OTF aligning with Terraform Cloud/Enterprise APIs, it would be beneficial to support both Sentinel and OPA, or at least design the schema in a way that allows for future support of multiple policy engines. In the TFE API, this is handled via a kind property. Without handling at the very least the schema/API-level support for both now it would leave future implementation of the alternative to potentially introduce breaking changes.

It would also be useful to allow specifying engine version (w/ latest option), similar to how OTF currently handles Terraform and OpenTofu versions. TFE exposes this as well, which gives users better control over compatibility and upgrade behavior.

On a related note, the engine version currently appears to be hardcoded in the Dockerfile, and only available within otfd. This makes it difficult to use in agent-based deployments or k8s jobs.

[Ilansos]

@Ilansos The 2026/03/31 19:07:35 http: TLS handshake error from 127.0.0.1:59546: remote error: tls: unknown certificate errors can safely be ignored. They're not the reason your tests are failling. I think you just need to revert your last few commits and it'll start working again. I posted a fix earlier for broken tests:

5cbffc3

Thanks, I will revert the commits i did to resolve the issue and merge master with my branch and will test it

[Ilansos]

A few notes on the current implementation; feel free to take them in context, especially since policy support isn’t something I’m actively using right now.

Given the spirit of OTF aligning with Terraform Cloud/Enterprise APIs, it would be beneficial to support both Sentinel and OPA, or at least design the schema in a way that allows for future support of multiple policy engines. In the TFE API, this is handled via a kind property. Without handling at the very least the schema/API-level support for both now it would leave future implementation of the alternative to potentially introduce breaking changes.

It would also be useful to allow specifying engine version (w/ latest option), similar to how OTF currently handles Terraform and OpenTofu versions. TFE exposes this as well, which gives users better control over compatibility and upgrade behavior.

On a related note, the engine version currently appears to be hardcoded in the Dockerfile, and only available within otfd. This makes it difficult to use in agent-based deployments or k8s jobs.

Hi, thanks for your remarks, I will first try to resolve the tests issues and will close this PR and work to implement your suggestions. The engine version is a little tricky since from my work with terraform enterprise this is not something you choose at runtime but I will check if it's possible to add.

[Ilansos]

A few notes on the current implementation; feel free to take them in context, especially since policy support isn’t something I’m actively using right now.

Given the spirit of OTF aligning with Terraform Cloud/Enterprise APIs, it would be beneficial to support both Sentinel and OPA, or at least design the schema in a way that allows for future support of multiple policy engines. In the TFE API, this is handled via a kind property. Without handling at the very least the schema/API-level support for both now it would leave future implementation of the alternative to potentially introduce breaking changes.

It would also be useful to allow specifying engine version (w/ latest option), similar to how OTF currently handles Terraform and OpenTofu versions. TFE exposes this as well, which gives users better control over compatibility and upgrade behavior.

On a related note, the engine version currently appears to be hardcoded in the Dockerfile, and only available within otfd. This makes it difficult to use in agent-based deployments or k8s jobs.

Implemented two related changes in the policy runtime and organization settings flow:

• First, policy engine support was generalized so the schema and runtime can accommodate more than one engine in the future. Policy sets now carry engine metadata, the runtime resolves Sentinel dynamically instead of relying on a Dockerfile-baked binary, and the execution path was refactored around engine-aware evaluation and binary resolution

• Second, Sentinel version selection was moved from per-policy-set configuration to organization settings. Organizations now persist a sentinel_version value, default it to latest

[Ilansos]

@leg100 @mlanth
Hi, I would like for your inputs if you think the PR is good to be merged or you think more work is needed.
Thanks in advance!

[leg100]

@Ilansos This is a very large PR. I won't be able to review it for quite some time.

[Ilansos]

@Ilansos This is a very large PR. I won't be able to review it for quite some time.

No problem, take your time with it. I just made a few new commits to resolve merge conflicts