[feature]: Support and Documentation for setting up user-application RBAC and role mapping.

mschnee commented 2 weeks ago

Prior Search

[X] I have already searched this project's issues to determine if a similar request has already been made.

What new functionality would you like to see?

The modules already describe some basic roles for RBAC. There are several third-party applications (Grafana, SonarQube, etc) that have their own "roles", and kube_monitoring is an example where grafana can be configured to determine a grafana-role name based on cluster-defined rbac fole name (here https://github.com/Panfactum/stack/blob/main/packages/infrastructure/kube_monitoring/main.tf#L1387)

However, a cluster may contain applications for numerous audiences beyond just superuser, admin, writer, reader.

How would you use this new functionality?

I would like to be able to easily describe a role and membership for an OIDC provider/client application.


inputs = {
  roles = {
    # This is the name of an Application Role
    'manage-books': [
      # This is a list of Groups a user may be in.
      'Librarian',
      'Staff Admin',
    ],
    'checkout-books': [
      'Librarian',
      'Staff Admin',
      'Receptionist',
      'Building Security'
    ]
  }
  # If you select into this role, you need to verify with totp.
  roles_requiring_totp = [
    'manage-books
  ]
  # The OIDC urls
  redirect_urls = [
    'https://my.library.com/oauth2/callback'
  ]
}

outputs = {
  client_id,
  client_secret, # if applicable
  issuer_url
}

fullykubed commented 2 weeks ago

I agree that there should be some documentation to describe how I'd recommend doing this.

However, in the interim, I just want to highlight that this is definitely possible, just not built in to the foundational stack which only preinstalls 5 standard roles. You would just need to create and apply your own IaC to extend the stack which should be fairly straightforward.

Can I ask what roles you need your applications need to support beyond the 5 standard ones?

mschnee commented 2 weeks ago

Sure! From the lens of the "applications" that need different roles:

The Stack itself: We have the "Release Ops Engineering Team" which can invoke terragrunt/tofu commands, can apply changes to the infra, and write code. Essentially, these members are assigned the standard roles.
SonarQube, an application deployed in the stack. We want to define roles such as cloud-developer-admin and cloud-developer for all of the engineers that work in the cloud but are not actually members of the "Release Ops Engineering" team.
The Release Operations Webapp tool: we want to define a number of roles such as rom-admin and rom-ops, and finally rom-guests. This will allow different groups different functionaliy to use this particular tool. For example, rom-guests can use the tool to make requests for content through the system, rom-ops can approve and fulfill those requests, and rom-admin can modify the content and rules available through that tool.
Some Future Experiment: an application that a small team may want to be able to prototype using our stack, where they define roles and can either describe a mapping of Active Directory security groups to populate, or possibly hard-code user emails.

mschnee commented 5 days ago

From the standpoint of the organization(s):

There are several thousand people across multiple companies/organizations.
Each of these companies maintains their own source-of-truth identity provider (most of them are ADFS) and they manage their own groups. Most have hundreds of security groups, and in general any given user is a member of over a dozen groups.

In our (future) production infrastructure, we are deploying several first-party and third-party applications. Each of these applications are intended for different audiences. Where the standard roles make sense for levels of authorization in each deployed application, it is unclear how to describe or configure how the thousands of people in hundreds of groups get access to the deployed applications in the role that they are authorized to assume.

fullykubed commented 2 days ago

Thank you for the clarification. This has helped me better understand the question.

As you can tell from the lack of documentation we currently have, we do not have specific recommendations for this type of expansive scenario.

A reason for this is that once you get past the basic RBAC setup, things tend to get very complicated, not just technologically but also with having to address a specific organization's unique constraints and legacy. As a result, I am not sure there exists a "best practice" recommendation that would apply to every organization.

A large part of the value in our enterprise plan is helping customers shape the foundational stack to work in their organization's context. Thus far, no customer has yet ended up with an identity setup that looks exactly the same.

That said:

I know that it is 100% possible using the tools available in the stack to accomplish what you are looking for.
The foundational documentation must definitely be improved so users can better understand what options are available to them. We will endeavor to work on that before the next stable release.

mschnee commented 1 day ago

Fantastic! I'm looking forward to that, as well as being able to provide potential recipes as we implement a solution here for our own needs.

Panfactum / stack