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

Authorization feature spec #76

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

Conversation

zachcasper
Copy link

No description provided.

@zachcasper zachcasper marked this pull request as ready for review November 25, 2024 22:25
Signed-off-by: Zach Casper <[email protected]>
Copy link
Contributor

@willtsai willtsai left a comment

Choose a reason for hiding this comment

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

Overall this is a great start, many details that nicely clarify things. I suggest adding a table to illustrate the matrix of roles and permissions you propose to put in place to help summarize things a bit.

architecture/2024-11-authz-feature-spec.md Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Outdated Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Outdated Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Outdated Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Outdated Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Outdated Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Show resolved Hide resolved
@zachcasper zachcasper requested review from a team as code owners November 26, 2024 20:33
Signed-off-by: Zach Casper <[email protected]>
@zachcasper zachcasper changed the title Initial draft of AuthZ feature spec Authorization feature spec Nov 27, 2024
architecture/2024-11-authz-feature-spec.md Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Outdated Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Outdated Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Show resolved Hide resolved
architecture/2024-11-authz-feature-spec.md Outdated Show resolved Hide resolved
# Grant permissions to CRUDL applications in the scoped resource group
- Applications.Core/applications/*
# Restrict using any resource type except those in the MyCompany.App namespace
- MyCompany.App/*
Copy link
Contributor

Choose a reason for hiding this comment

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

Just thinking aloud, but it would be really fun to demo this with a rad role-definition edit (like kubectl edit).

I think that creates a really strong narrative about customization.

architecture/2024-11-authz-feature-spec.md Outdated Show resolved Hide resolved

> [!NOTE]
>
> The UI should refer to resources with the fully qualified name unless the resource group context is obvious. In the examples below, The application is referred to as "getting-started" since the "app-getting-started" resource group was referenced. But the environment is referred to as "env-default/my-kube-context" since it was not previous referenced.
Copy link
Contributor

Choose a reason for hiding this comment

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

+1

This is an obvious improvement we can make to a bunch of experiences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants