Conversation
|
Because we had it yesterday with OpenLineage: I believe it could make sense to add a "path" or "endpoint" field. Just in case DataHub is deployed behind some proxy. :// |
Good point! For consistency reasons with UIF and AuthenticationClass I went with |
Maleware
left a comment
There was a problem hiding this comment.
Just two typos, thanks you! Test passes locally, thus LTGTM otherwise.
| } | ||
|
|
||
| /// Generates the trivial `From<Params> for ResourceInfoRequest` conversions, so each HTTP handler | ||
| /// can turn its deserialized query parameters into a [`ResourceInfoRequest`] via `.into()`. Adding a |
There was a problem hiding this comment.
| /// can turn its deserialized query parameters into a [`ResourceInfoRequest`] via `.into()`. Adding a | |
| /// can turn its deserialized query parameters into a [`ResourceInfoRequest`] via `.from()`. Adding a |
There was a problem hiding this comment.
https://doc.rust-lang.org/std/convert/trait.From.html
From automatically implements Into, so the caller can pick.
In
Into<ResourceInfoRequest>. In general I feel in this situation a into feels more natural than a from
There was a problem hiding this comment.
Ah okay allright. I was looking at the function beneath which reads from thought that might want to match.
Co-authored-by: Maximilian Wittich <56642549+Maleware@users.noreply.github.com>
|
Please vote on the CRD change as well as the rego rule API on this comment. Feel free to also look at the JSON API, but I'd say that's an implementation detail we are allowed to change in the future |
maltesander
left a comment
There was a problem hiding this comment.
First round, did not check docs etc. properly yet and not testing yet.
| // Trim trailing whitespace/newlines so the value is safe to use in an HTTP header. | ||
| let token = tokio::fs::read_to_string(&token_path) |
There was a problem hiding this comment.
This is never refreshed? Will go stale and produce 401 until restart?
There was a problem hiding this comment.
Yes, but ResolvedKeycloakBackend::resolve, ResolvedEntraBackend::resolve, ResolvedOpenLdapBackend::resolve and maybe others do the exact same thing.
According to https://docs.datahub.com/docs/authentication/personal-access-tokens you can create a PAT without expiration.
I see that is not 100% ideal, but also IMHO the status quo basically everywhere else in the platform as well
There was a problem hiding this comment.
No i dont think so. They read the client credentials, not the token?
(same for entra).This is not ideal either, we should just cache it and refresh on 401.
| /// | ||
| /// [`urn_for_request`]: crate::backend::data_hub::resource_to_urn_mapping::urn_for_request | ||
| #[derive(Debug, Clone, PartialEq, Eq, Hash)] | ||
| pub enum ResourceInfoRequest { |
There was a problem hiding this comment.
The instance is always required. Datahub (defaults) leave that out and a trino table will become e.g. urn:li:dataset:(urn:li:dataPlatform:trino,tpch.sf1.customer,PROD) and the tableResourceInfo always builds {instance}.tpch.sf1.customer which will be empty and therefore fail a correct rego?
Can we make instance optional and skip?
There was a problem hiding this comment.
I was thinking of this as well (I actually started without the instance).
I think we should very strongly recommend users to set the instance when ingesting data into DataHub.
Also we likely want to support other backends in the future.
If they don't have such a strange concept of "there is only one Trino" they will require us to send a instance for every request.
So I fear we would have a problem with future backends if we make it optional.
There was a problem hiding this comment.
Hmm i dont think we should strongly recommend how people use a non stackable product?
I think the scope of this PR is datahub, so i would try to represent everything datahub can do with reasonable abstraction? Removing the optional part can then be done once another backend lands?
I feel this is a too generalized and therefore cutting into datahub funtionality?
I also had to refactor the crd mod to be only pulled in via lib.rs to fix clippy warnings
maltesander
left a comment
There was a problem hiding this comment.
Claude reproduced a bigger security issue (policies can pass if backend is gone).
Silent fail-open when the backend is unavailable
| Backend state | allow if tag==public |
deny if tag==pii |
|---|---|---|
| healthy | deny | deny ✅ |
| PAT rejected (401) | deny | allow ❌ |
| GMS scaled to 0 | deny | allow ❌ |
All three containers report ready=true throughout. There is no readiness probe on the sidecar.
- Repro:
kubectl -n $NS scale deploy datahub-datahub-gms --replicas=0, wait 60s for the cache to drain, query any policy that excludes a tag. - Fix: add a readiness probe in
controller/build/resource/daemonset/resource_info_fetcher.rs
Tags and domains are not inherited from the parent container
Tagging schema tpch.sf1 with pii leaves child table nation reporting tags:[public], domain:null. A deny if pii policy allows it. DataHub exposes the parent in the same query (container { tags domain }), so this is one field away.
- Repro:
addTag/setDomainon the schema container URN, wait out the 60 s TTL, query the table. - Fix: add
container { tags {...Tags} domain {...Domain} }to the fragment atgraphql.rs:30, or state the non-inheritance explicitly in the docs.
| Self::ConstructHttpClient { .. } => StatusCode::SERVICE_UNAVAILABLE, | ||
| Self::BuildDataHubEndpoint { .. } => StatusCode::BAD_REQUEST, | ||
| Self::ExecuteGraphQlQuery { .. } => StatusCode::INTERNAL_SERVER_ERROR, | ||
| Self::GraphQlErrors { .. } => StatusCode::INTERNAL_SERVER_ERROR, |
There was a problem hiding this comment.
I think this is user-controlled, e.g. a bad identifier is rather a client error?
| Self::GraphQlErrors { .. } => StatusCode::INTERNAL_SERVER_ERROR, | |
| Self::GraphQlErrors { .. } => StatusCode::BAD_REQUEST, |
Description
Part of #848
Yes, the diff looks big, but most of it are lockfiles and kuttl tests
CRD change
Basically the same as for the user-info-fetcher. The only difference is the
envfield, which is DataHub specific.Look at
extra/crds.yamlfor the concrete CRD changeAPI of RIF
The rego rules and HTTP API of RIF: https://github.com/stackabletech/opa-operator/blob/spike/rif/docs/modules/opa/pages/usage-guide/resource-info-fetcher.adoc
Definition of Done Checklist
Author
Reviewer
Acceptance
type/deprecationlabel & add to the deprecation scheduletype/experimentallabel & add to the experimental features trackerRelease notes
Added
For now only DataHub is supported.
Also, a rego-rule library has been added to make it easier to call resource-info-fetcher from within OPA.
The API (especially the response) might change in the future once more data catalogs are supported
Nightly docs
As soon as this PR is merged the docs will show up at https://docs.stackable.tech/home/nightly/opa/usage-guide/resource-info-fetcher/