Feat/opa mgmt

[SteBaum]

Description

Adds an option to add Kube-managment for OPA. OKDP-examples has been updated to include the ConfigMaps necessary for OPA with the Kube-managment sidecar.

Moreover, OPAL is only deployed if the option enableOPA is true. Before it was deployed but not used by Trino. And Trino does no longer wait for OPAL or to be ready to start deploying.

Finally, decision logs and status logs in OPA have been activated for easier debug.

Related Issue

Fixes #44

Type of Change

• Bug fix
• New feature
• Documentation update
• Refactor / chore
• Breaking change

How to Test

Checklist

• I have tested my changes
• Documentation updated if needed
• If breaking change: migration path described above
• I hereby declare this contribution to be licensed under the Apache License Version 2.0.
• I hereby agree to grant TOSIT a copyright license to use my contributions.

[SteBaum]

Needs to be merged after okdp-examples.

[abir-oumghar]

Tested this locally on a kind sandbox: suspended the kubocd Release, applied the HelmReleases rendered from this branch, then restored everything.

The change does what it says. It renders correctly in all three modes, the OPA pod comes up 2/2 with the kube-mgmt sidecar, policy and data load from the labeled ConfigMaps, and enforcement works end to end through Trino: SHOW CATALOGS returns 3 of the 5 configured catalogs, tpch is denied, and a real query on bronze.nyc_tlc.yellow goes through. 10 targeted allow and deny decisions all landed as expected. The okdp-examples bump is clean too, 1.3.0 only adds the two ConfigMaps and nothing else.

And the bug you are fixing is very real: on my sandbox enableOPA: false, yet OPA and OPAL were both running.

One thing I would like to sort out before merge.

With the defaults (enableOPA: true, enableOPAL: false) the policies come only from ConfigMaps shipped by the okdp-examples package. I deleted those two ConfigMaps and every query died:

SHOW CATALOGS -> Access Denied: Cannot execute query
SELECT 1      -> Access Denied: Cannot execute query

Fail closed, which is the safe direction, but it means a default Trino install is unusable unless okdp-examples runs in the same namespace. trino.yaml declares dependencies: [data-catalog, ingress] and says nothing about okdp-examples, which is a demo package nobody would install on a production platform. Before this PR the default path used OPAL pulling from git, so trino stood on its own.

[SteBaum]

Tested this locally on a kind sandbox: suspended the kubocd Release, applied the HelmReleases rendered from this branch, then restored everything.

The change does what it says. It renders correctly in all three modes, the OPA pod comes up 2/2 with the kube-mgmt sidecar, policy and data load from the labeled ConfigMaps, and enforcement works end to end through Trino: SHOW CATALOGS returns 3 of the 5 configured catalogs, tpch is denied, and a real query on bronze.nyc_tlc.yellow goes through. 10 targeted allow and deny decisions all landed as expected. The okdp-examples bump is clean too, 1.3.0 only adds the two ConfigMaps and nothing else.

And the bug you are fixing is very real: on my sandbox enableOPA: false, yet OPA and OPAL were both running.

One thing I would like to sort out before merge.

With the defaults (enableOPA: true, enableOPAL: false) the policies come only from ConfigMaps shipped by the okdp-examples package. I deleted those two ConfigMaps and every query died:

SHOW CATALOGS -> Access Denied: Cannot execute query
SELECT 1      -> Access Denied: Cannot execute query

Fail closed, which is the safe direction, but it means a default Trino install is unusable unless okdp-examples runs in the same namespace. trino.yaml declares dependencies: [data-catalog, ingress] and says nothing about okdp-examples, which is a demo package nobody would install on a production platform. Before this PR the default path used OPAL pulling from git, so trino stood on its own.

When I have enableOPA set to false, no OPA nor OPAL is deployed whether enableOPAL is set to true or not.

Of course Trino will not work if enableOPA is set to true and enableOPAL is et to false and if no OPA policy and data ConfigMaps have been created. The ConfigMaps in okdp-examples are a copy of the policy and data in the trino_opa_policy folder of the same repository which is cloned by OPAL if you use it. If you do not have okdp-examples you will have to do your own policies which is intended.