-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open Policy Agent engine evaluation per tenant #170
Conversation
transactionRequest?: TransactionRequest | ||
principal: CredentialEntity | ||
resource?: { uid: string } | ||
approvals: CredentialEntity[] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@samteb why are the approvals always required? Is it because the principal always approves the request, so it'll always have at least one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel we have a misaligned somewhere because the Evaluation Request specifies the approvals as optional.
export type EvaluationRequest = {
authentication: JwtString
request: Request
approvals?: JwtString[]
transfers?: HistoricalTransfer[]
prices?: Prices
feeds?: Feed<unknown>[]
}
Original commit: 33ae82c
It was moved to Open Policy Agent module.
Check encryption configuration at the bootstrap.
4dad927
to
9fbfc98
Compare
Note: - Engine signing is currently a proof of concept. It's unclear how it will evolve with remote signing, so I'd rather not modify it at this point. - Building OPA targeting WASM involves a process with many steps that interact with the OS and its file system. The current implementation addresses the happy path and a few obvious errors. Therefore, error handling for edge cases is not yet implemented, and I expect these to be addressed as we encounter issues in the building process. - The whole implementation is in a single place (see `wasm-build.util.ts`). Changelog: - Added a core Engine interface along with an Open Policy Agent implementation of it, effectively hiding OPA as an implementation detail. Everything outside the `apps/policy-engine/src/open-policy-agent` directory SHOULD NOT have knowledge of OPA and Rego. - Added temporary code in the BootstrapService to add a development tenant pointing to the devtool stores. - Added a `resource` directory for the server to access files from the disk. - Added a `RESOURCE_PATH` environment variable because we can't depend on `__dirname` to resolve the path. Its value changes based on how the application is built. With webpack, it minimizes, and `__dirname` always points to the lowest level of the directory tree. By contrast, in tests, the directory tree is preserved because files are transformed on the fly. - Added the resource directory as a NestJS assets directory in `project.json`. - Changed the Rego core directory to `apps/policy-engine/src/resource`. - Removed most of the legacy OPA code. - Changed the tenant module location to the engine module due to numerous circular dependency issues in the DI container. - Note: it felt like a good example of unclear module boundaries, and I'd rather roll it back and see how it evolves than trying to address problems we SHOULD NOT have. Co-authored-by: samuel <[email protected]>
Note
wasm-build.util.ts
).Changelog
apps/policy-engine/src/open-policy-agent
directory SHOULD NOT have knowledge of OPA and Rego.resource
directory for the server to access files from the disk.RESOURCE_PATH
environment variable because we can't depend on__dirname
to resolve the path. Its value changes based on how the application is built. With webpack, it minimizes, and__dirname
always points to the lowest level of the directory tree. By contrast, in tests, the directory tree is preserved because files are transformed on the fly.project.json
.apps/policy-engine/src/resource
.