Refactor Authorization and Project Configurations in Central Dogma

[minwoox]

Summary

The current authorization system in Central Dogma has several limitations and issues regarding security, role permissions, and project management. This proposal addresses these issues by refining roles and permissions, adding visibility options, and improving configuration management.

Problems and Limitations

1. Insecure Anonymous Role

   • Current State: Central Dogma includes an Anonymous role that allows repository access without authentication.
   • Issue: Exposing repositories to unauthenticated users is a security risk.
   • Solution: Remove the Anonymous role entirely to restrict access to logged-in users only.

2. Ineffective Guest Role and Repository Visibility

   • Current State: The Guest role can have read or write permissions, which is not ideal for permissions management. It can make sensitive information vulnerable.
   • Issue: The existence of a Guest role with write permissions is unusual, and it limits options for repository visibility.
   • Solution: Eliminate the Guest role. Introduce a visibility option (public or private) at the repository level:
     • Private repositories: Only accessible to authenticated users with explicit permissions.
     • Public repositories: Available to all authenticated users for read access.

3. Limited Project-Level Permissions

   • Current State: A project in Central Dogma has multiple repositories, but project owners cannot easily assign permissions to individual repositories within the project. Currently, a user must be registered as a project member to access specific repositories.
   • Issue: This constraint makes it challenging to manage permissions across multiple repositories in a single project.
   • Solution: Implement fine-grained repository-level permissions that do not require project-level membership. This will allow project owners to control permissions for each repository independently.

4. Lack of Team Structure

   • Current State: All permissions must be set individually, as Central Dogma lacks team-based access control.
   • Issue: Managing access at an individual level can be tedious and error-prone, especially for large teams.
   • Solution: Introduce team-based access control, allowing permissions to be assigned to teams instead of individual users.

5. Terminology Alignment with Industry Standards

   • Current State: Central Dogma uses Admin to describe the Central Dogma cluster owner, but GitHub and similar platforms use Admin for repository ownership, which may cause confusion.
   • Issue: Users may confuse Central Dogma cluster-level administration with repository-level ownership.
   • Solution: Rename Admin (the term used for cluster owners) to something clearer and more intuitive. Proposed name: ClusterAdmin.

6. Improvement of Configuration Storage for Projects and Repositories

   • Current State: Configuration information, such as mirroring and credentials, is stored in the meta repository at the project level. Accessing this information requires WRITE permissions on the meta repository, which will be hidden.
   • Issue: The meta repository will be hidden to public users, which restricts management of configurations.
   • Solution: Move configurations to a repository-specific level:
     • Each repository should handle its mirroring and credential configurations directly, removing the need for project-level storage of this information.
     • Give permission to repository Admins for accessing the information.

---

Proposed Changes

Role and Permission Revisions

• Remove Anonymous Role: Ensure all repositories require authenticated access.
• Remove Guest Role: Instead, introduce repository visibility settings:
  • Public: Readable by all authenticated users.
  • Private: Only accessible to users with assigned permissions.

Enhanced Project and Repository Permissions

• Allow project owners and repository owners to assign permissions directly to individual repositories without requiring project membership.

Team-Based Access Control

• Implement team-based roles to simplify and organize permissions management, enabling efficient control over access for larger groups.

Terminology Update

• Rename Cluster-Level Admin: Change the Admin designation for the cluster owner to ClusterAdmin (or other suggestions welcome) to align terminology more closely with industry standards.

Configuration Management Improvements

• Repository-Level Configurations:
  • Migrate mirroring and credential configurations to the repository level.

---

Goals and Benefits

• Increased Security: Removing anonymous access and restricting visibility.
• Improved Usability: Enhanced permission management with public/private repositories and team-based roles.
• Clearer Terminology: Reduced confusion by aligning Central Dogma’s terminology with industry standards.
• Easier Configuration Management: Repository-specific configurations provide a cleaner, more accessible structure.

---

[ikhoon]

Change the Admin designation for the cluster owner to ClusterAdmin (or other suggestions welcome)

System Admin?

[jrhee17]

Overall, it seems like the proposal is to modify the current CD structure to follow Github more closely and I agree this is simpler for users to reason about.

Having said this, some thoughts:

• It seems like the proposal includes some breaking changes (1), (2). I'm curious how you propose to migrate these features.
• About (6), will meta related information still be managed by a git repository in the project level? If the proposal is to save to a separate file in the file system, we won't have access to features such as concurrent writes/history management. A detailed proposal on the new directory layout may be helpful to understand the exact goal.
• Note: For (5) I understood that not only UI, but also APIs will also need to be changed.
• It seems like this issue is an umbrella for multiple issues. It might be useful to know which feature aligns with what goal to easily manage priorities. For instance, it seems like (4) can be done independently and does not relate to xDS directly.

[minwoox]

Thank you for your feedback. 👍

It seems like the proposal includes some breaking changes (1), (2). I'm curious how you propose to migrate these features.

If this approach is acceptable, I’d be happy to provide a detailed migration plan. Here’s a brief outline:

• Remove anonymous access entirely
• Introduce public and private repository options
  • Automatically migrate existing repositories with guest READ permissions to public repositories.

It seems like the proposal includes some breaking changes (1), (2). I'm curious how you propose to migrate these features.

That's a good question. 👍 For now, meta-related information will continue to be managed at the project level within the meta repository (1). If needed, we may later separate it into each repository’s individual meta repository (2). During phase (1), the meta file will include sections dedicated to each repository, so concurrent writes will be managed efficiently, with only minimal delays due to commit sequencing. Additionally, history tracking for the configuration is not currently provided, but we can support it with ease if needed in the future.

Note: For (5) I understood that not only UI, but also APIs will also need to be changed.

Which APIs are you talking to?

It seems like this issue is an umbrella for multiple issues. It might be useful to know which feature aligns with what goal to easily manage priorities. For instance, it seems like (4) can be done independently and does not relate to xDS directly.

This isn’t intended to address specific issues; rather, it’s part of a broader effort to enhance the authorization system in Central Dogma based on improvements identified during usage. Please consider it as a general refactoring of the authorization and configuration systems in Central Dogma.

[jrhee17]

Which APIs are you talking to?

e.g. there may be more, but this comes to mind

https://github.com/line/centraldogma/blob/755b3b416aa1497e34ac661372b460e81e932e26/server/src/main/java/com/linecorp/centraldogma/server/internal/api/TokenService.java#L108

It’s part of a broader effort to enhance the authorization system in Central Dogma based on improvements

I think as an overall direction the approach seems good. I guess my question was more about how much resources are we investing to this improvement.

As an overall direction, the proposal seems good though.

[minwoox]

there may be more, but this comes to mind

Oh, I forgot that API. Yeah, I need to fix that as well. 😉

I guess my question was more about how much resources are we investing to this improvement.

Good point. I’m not entirely certain about the exact resources that I need to put. My goal is to complete it this quarter, though it may extend beyond that. However, I believe this improvement is essential to enhancing Central Dogma as a valuable product. 😉