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.

Sign up for GitHub

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

[WIP] proposal: extending ldap support for different types of users #19

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

[WIP] proposal: extending ldap support for different types of users #19

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
df84c09
proposal: extending ldap support for different types of users
kleesc Jul 8, 2022
55ef3e4
WIP: implemetation details
kleesc Aug 18, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 28 additions & 0 deletions enhancements/extending-ldap.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -85,3 +85,31 @@ defined LDAP entity.
## Implementation History

- 2022-07-08 Initial proposal


### Implementation

#### Superusers

In addition to current superuser capabilities, this implementation will add the ability for superusers to access contents from outside its permission scope. This is a very specific use case and would only be enabled if the given FEATURE flag is set. This would allow superusers, on top of taking ownership of other namespaces, read, write, and delete contents from other namespaces, without breaking backward compatibility (i.e exising installations should be able to opt-in to get this behavior).

In terms of permission, access to resources not owned by the user would be granted based on whether or not that user has the existing superuser grant (scope) or not. This means that superusers would essentially bypass standard authentication in these cases. TODO: security implications.
Copy link

Choose a reason for hiding this comment

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

Does this include user orgs?

Copy link

Choose a reason for hiding this comment

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

Are there any concerns about a superuser being able to sidestep auditing?

Copy link

Choose a reason for hiding this comment

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

Is it really sidestepping auditing? I read here that it would be sidestepping standard authentication. And I am not sure why it would have anything to do how the user authenticates. The superuser still always has to authenticate with credentials. Is it possible that this was meant to say "authorization"? If so, the standard authorization should be adjusted to always grant the superuser to anything it request. It is the superuser after all.

Copy link

Choose a reason for hiding this comment

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

Is it possible that this was meant to say "authorization"?

I think so. Superuser actions should still be audited though, but giving them the ability to do anything makes it sound like they could then tinker with auditing...which would defeat the purpose of auditing the actions.


#### Restricted Users

Restricted users are a subset of Quay users whose capabilites will be a subset of current regular Quay users (excluding superusers). Some limitations we're going to impose are:
- Inability to create organizations
- Inability to write (Feature flagged. Should this be enforced on owner's namespace, or just enforced through quota?)
Copy link

Choose a reason for hiding this comment

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

I'm thinking enforced on the owner's namespace, otherwise we'd be coupling quota to security.

Copy link

Choose a reason for hiding this comment

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

This will also prevent users from writing to their own org, right?

- Feature flag/whitelist to default new users as restricted (when not using LDAP, or other federated provider)

Like superusers, restricted users are defined in LDAP using a filter or group. When LDAP is not used, unlike how superusers are defined in a list in Quay's configuration, restricted users are defined based on a provided whitelist (i.e users are defined as restricted unless specified in that configuration list).
Copy link

Choose a reason for hiding this comment

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

How will we handle situations where users are members of multiple ldap groups that have different levels of permissions? For example, a group called admin that contains a user bob and a group called users that also contains bob. Guessing highest level of permission will be what is granted?

Copy link

Choose a reason for hiding this comment

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

I'd would expect it to be that: highest level of permission will be what is granted.


When that list is not set, then this feature should implicitly not be enabled (only in the case where LDAP is not used.

#### Configuration

`FEATURE_SUPERUSERS_FULL_ACCESS`: Whether to grant superusers full access no namespaces not owned
`FEATURE_RESTRICTED_USERS`: Whether to enable restricted users
`RESTRICTED_USERS_WHITELIST`: Defines the list of users who are not limited by the restricted users' constraints (i.e regular Quay user)
`LDAP_SUPERUSER_FILTER`: Filter for selecting ldap superusers. Relative to the LDAP_USER_FILTER.