config(rest-api): enable authentication and api authorization by default

[david-leifker]

• breaking change (previously disabled by default)
• upgraded pytests for running with authentication enabled

Checklist

• The PR conforms to DataHub's Contributing Guideline (particularly Commit Message Format)
• Links to related issues (if applicable)
• Tests for the changes have been added/updated (if applicable)
• Docs related to the changes have been added/updated (if applicable). If a new feature has been added a Usage Guide has been added for the same.
• For any breaking change/potential downtime/deprecation/big changes an entry has been made in Updating DataHub

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[Masterchen09]

@david-leifker First, I wanted to include this in my PR for the Helm chart...however I think here it is probably better...

I have already noticed it sometime ago - we have enabled the REST API authorizations for our deployment for some time - and I also have tried to fix it, however the whole policy logic is a bit hard to follow (i.e. the PolicyConfig.java is just too big and is confusing if you try to understand it...there are plain privileges, then they are grouped somehow in READ, WRITE, etc. and then there is CRUD-like structure which is used "somehow"): Currently some of the privileges which are affected by the REST_API_AUTHORIZATION_ENABLED environment variable cannot be assigned to custom policies using the UI because the privileges are missing in the corresponding list in PoliciesConfig.java (see also this comment here). These privileges are only granted to the DataHub Root User and the Admin role, but cannot be included in custom policies.

Not sure, but I think this is something which must be checked if the REST API authorizations are enabled by default now, at least the privileges which have nothing to do with the GraphQL endpoints (as the comment linked above suggests, although I do not fully understand the logic why something should or should not be included in the list) should be available as privileges in the UI:

RESTORE_INDICES_PRIVILEGE
ES_EXPLAIN_QUERY_PRIVILEGE
GET_ES_TASK_STATUS_PRIVILEGE
GET_TIMESERIES_INDEX_SIZES_PRIVILEGE
SET_WRITEABLE_PRIVILEGE
APPLY_RETENTION_PRIVILEGE
PRODUCE_PLATFORM_EVENT_PRIVILEGE

edit: Maybe all platform privileges could be included in the PLATFORM_PRIVILEGES list without having an impact on the GraphQL endpoints?

[david-leifker]

@Masterchen09 - There is some history with how the policy privileges have evolved over time. Initially, APIs like OpenAPI and Rest.li were authenticated only with no authorization checks.

The initial implementation of OpenAPI/Rest.li was built similar to graphql privileges where they were higher level and usually simple allow or deny. This simplicity didn't satisfy more complex access control rules which needed CRUD semantics for authorization. This was added later to all APIs (where possible for graphql) in order to be able to have a somewhat consistent authorization policy across all APIs.

The privileges listed are privileges that were created for either OpenAPI or Rest.li and since these APIs were considered separate from graphql /UI they were never added to the UI to prevent confusion because there is no way to exercise them in the UI or via graphql.

While those privileges are not part of the UI, you can create policies via APIs to include them. As you pointed out the typical users for those privileges are admin or Admin role only and are not exactly useful for anyone but a user of the OpenAPI or Rest.li APIs (this does include the cli users).

Hopefully that explains how we got to this point. As to whether we should include these in the UI, even though they are not part of the UI experience, I'd want to get input from product @chriscollins3456 @jjoyce0510

[david-leifker]

I'd have to review some of those privileges, however it might be less confusing to add like MANAGE_SYSTEM_OPERATIONS to the UI and consolidate those other permissions into 1. The others would still be respected, but it would be less confusing to the average user.

[david-leifker]

See #11549