Skip to content
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

add optional system schema authorization #11720

Merged
merged 5 commits into from
Sep 21, 2021

Conversation

clintropolis
Copy link
Member

Description

Builds on top of #11692 to add optional authorization to tables of the sys in SQL as SYSTEM_TABLE resources, if
the newly added druid.sql.planner.authorizeSystemTablesDirectly is true. For backwards compatibility, this feature is off by default. This allows cluster operators to selectively enable access to sys schema tables, or even disallow completely while still allowing SQL access to Druid datasources (DATASOURCE resources).

Because of the smooth way things were done in #11692, the actual code change here is pretty small, NamedSystemSchema now accepts the PlannerConfig so it can optionally return ResourceType.SYSTEM_TABLE. The
integration tests have been configured to now run with this new option enabled, and new authorization tests to cover this new permission. The majority of the changes in this PR are a slight refactoring of the authorization integration tests to share code a bit more effectively (and so I only had to add new tests once), and in fact right now at least this PR removes more lines than it adds even though it is adding new stuff.

This PR has:

  • been self-reviewed.
  • added documentation for new or modified features or behaviors.
  • added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
  • added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
  • added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
  • added integration tests.
  • been tested in a test Druid cluster.

@@ -29,11 +29,12 @@ This document describes the Druid security model that extensions use to enable u

At the center of the Druid user authentication and authorization model are _resources_ and _actions_. A resource is something that authenticated users are trying to access or modify. An action is something that users are trying to do.

There are three resource types:
There are four resource types:
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

heh this is actually a lie, there is also VIEW, but since there is no view implementation I don't think we need to call it out yet

Copy link
Contributor

@techdocsmith techdocsmith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Optional style changes

@@ -1763,6 +1763,7 @@ The Druid SQL server is configured through the following properties on the Broke
|`druid.sql.planner.sqlTimeZone`|Sets the default time zone for the server, which will affect how time functions and timestamp literals behave. Should be a time zone name like "America/Los_Angeles" or offset like "-08:00".|UTC|
|`druid.sql.planner.metadataSegmentCacheEnable`|Whether to keep a cache of published segments in broker. If true, broker polls coordinator in background to get segments from metadata store and maintains a local cache. If false, coordinator's REST API will be invoked when broker needs published segments info.|false|
|`druid.sql.planner.metadataSegmentPollPeriod`|How often to poll coordinator for published segments list if `druid.sql.planner.metadataSegmentCacheEnable` is set to true. Poll period is in milliseconds. |60000|
|`druid.sql.planner.authorizeSystemTablesDirectly`|If true, queries against any of the system schema tables (`sys` in SQL) will be authorized as `SYSTEM_TABLE` resources which require `READ` access, on top of their current permissions based filtering.|false|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
|`druid.sql.planner.authorizeSystemTablesDirectly`|If true, queries against any of the system schema tables (`sys` in SQL) will be authorized as `SYSTEM_TABLE` resources which require `READ` access, on top of their current permissions based filtering.|false|
|`druid.sql.planner.authorizeSystemTablesDirectly`|If true, Druid authorizes queries against any of the system schema tables (`sys` in SQL) as `SYSTEM_TABLE` resources which require `READ` access, in addition to permissions based filtering.|false|

@@ -29,11 +29,12 @@ This document describes the Druid security model that extensions use to enable u

At the center of the Druid user authentication and authorization model are _resources_ and _actions_. A resource is something that authenticated users are trying to access or modify. An action is something that users are trying to do.

There are three resource types:
There are four resource types:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
There are four resource types:
Druid uses the following resource types:

avoid specific number


* DATASOURCE – Each Druid table (i.e., `tables` in the `druid` schema in SQL) is a resource.
* CONFIG – Configuration resources exposed by the cluster components.
* STATE – Cluster-wide state resources.
* SYSTEM_TABLE – if `druid.sql.planner.authorizeSystemTablesDirectly` is enabled, then system tables (the `sys` schema in SQL) are authorized as this type of resource.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* SYSTEM_TABLE – if `druid.sql.planner.authorizeSystemTablesDirectly` is enabled, then system tables (the `sys` schema in SQL) are authorized as this type of resource.
* SYSTEM_TABLE – if `druid.sql.planner.authorizeSystemTablesDirectly` is enabled, then Druid authorizes system tables,`sys` schema in SQL, using this resource type.

@zachjsh zachjsh self-requested a review September 20, 2021 06:09
@@ -72,6 +72,7 @@ druid_coordinator_kill_supervisor_on=true
druid_coordinator_kill_supervisor_period=PT10S
druid_coordinator_kill_supervisor_durationToRetain=PT0M
druid_coordinator_period_metadataStoreManagementPeriod=PT10S
druid_sql_planner_authorizeSystemTablesDirectly=true
Copy link
Contributor

@zachjsh zachjsh Sep 20, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like it might be wasteful to have integration tests for both true and false, but since the default is disabled here, I think we may still want to have ITs for when this feature is disabled. What do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered this, I think it is ok to only test enabled because it just layers additional checks on top of the disabled code path, so with the newly added user we should still be covering all of the code paths that were previously tested, just distributed a bit differently.

Copy link
Contributor

@zachjsh zachjsh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. thanks for all the test refactoring @clintropolis . Just had one question about whether to keep the ITs with the new feature disabled in addition to it enabled as that is the default behavior.

@clintropolis clintropolis merged commit 5de26cf into apache:master Sep 21, 2021
@clintropolis clintropolis deleted the authorize-system-schema branch September 21, 2021 20:28
@clintropolis
Copy link
Member Author

thanks for review @techdocsmith and @zachjsh 👍

clintropolis added a commit that referenced this pull request Oct 8, 2021
* security recommendation

* Update docs/operations/security-overview.md

Co-authored-by: Victoria Lim <[email protected]>

* Update docs/operations/security-user-auth.md

Co-authored-by: Victoria Lim <[email protected]>

* Update docs/operations/security-user-auth.md

Co-authored-by: Victoria Lim <[email protected]>

* Update security-user-auth.md

add newline

* Update docs/operations/security-overview.md

Co-authored-by: Victoria Lim <[email protected]>

* Update security-overview.md

add suggestion for environment variable dynamic config provider

Co-authored-by: Victoria Lim <[email protected]>
Co-authored-by: Clint Wylie <[email protected]>
@abhishekagarwal87 abhishekagarwal87 added this to the 0.23.0 milestone May 11, 2022
@suneet-s suneet-s mentioned this pull request Jul 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants