KEP 60 - Role-based Access Control (RBAC)

[johannes-b]

Role-based Access Control (RBAC)

Success Criteria: Role-based and SSO-based access control need to be applied for accessing Keptn UIs and APIs.

Motivation

Target audience pain points
As any user entering the Bridge, I see all and everything there from my whole organization. I see things, I do not care about and even worse: I might also see things I should not be allowed to see (e.g. QG results including security vulnerability metrics for a certain release).

Evidence
Keptn users requested role-based access to the Bridge several times.

No discussion, that role-based access and visibility of company data is a must-have for any enterprise-ready solution.

What

What it is?

• As anyone looking into data in the Bridge, I should only authenticate once and have proper permissions within the Bridge based on my SSO roles.

• As an automation engineer, I should only edit the automation I'm responsible for.

• As a member of one department, I might not be allowed to see (and not allowed to edit) quality gates of another department.

What it is not

Use Cases

As an operator of Keptn, I can connect it to my OIDC/OAuth 2.0 provider (e.g, Keycloak, Okta, etc.)

Keptn has three roles: read / write / admin

• A read role allows you to:

  • Read all resources without enabling you to modify a resource

• A write role allows you to:

  • Modify all resources. E.g. approve a promotion in the bridge
  • The "write" role for a given stage should only permit any modifications within the same stage. E.g. if you have the "write" role in dev, but not in hardening it should not allow you to press the "promote" button in dev, since then modifications are done in hardening.

• An admin role allows you to:

  • Modify all resources, change the Keptn shipyard, create projects, ...

Roles in Keptn must be settable on project- / service- / (stage+service)- level

• Having a role on project-level enables you to perform an action in each stage for each service

  • E.g. when having the write role for service X you can approve any approval step for service X in any stage
  • Example use cases: define admins per project / give read permissions to business stakeholders

• Having a role on service-level enables you to perform an action only for the given service (in each stage)

  • E.g. when having the write role for service X you can approve any approval step for service X in any stage
  • Example use case: All members of a team can promote a service to the next stage

• Having a role on (stage+service)-level enables you to perform an action only for the given stage/service tuple

  • E.g. when having the write role for service X in stage Y you can only approve approval steps for service X in stage Y
  • Example use case: Only a handful of people can approve the promotion of a service to production

A role has one or more API tokens

The API tokens can be rotated

• That's why we need multiple API tokens per role: We want to prevent that access is lost during the time the API token is rotated

Slices of this KEP

This KEP is currently sliced into three epics:

• 1. Authentication: Support OIDC/OAuth2.0 [status: done ]
• 2. Local authorization for a read, write, admin user: [status is in refinement]
• 3. Full RBAC Authorization Management inside Keptn: [status is in refinement]

[johannes-b]

We should consider this aspect too: keptn/keptn#4833

[johannes-b]

Support OIDC/OAuth2.0

for Bridge/CLI/Distributor

• OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol.
• It enables Clients:
  • to verify the identity of the end-user (Keptn user) based on the authentication performed by an authorization server
  • to obtain basic profile information about the end-user (Keptn user) in an interoperable and REST-like manner.

• Examples of an OIDC/OAuth2.0 provider are: Keycloak, GitHub, Okta, etc.

Bridge

• Bridge: FF for OIDC keptn#6073
• Bridge: Implement OIDC flow keptn#6076
• Bridge: Token refresh keptn#6077
• Bridge: Send the access token as Bearer header keptn#6078
• Bridge: Document OIDC keptn#6082

CLI

• CLI: Add SSO flag to Auth command keptn#6083
• CLI: Send the access token as Bearer header keptn#6084
• CLI: Token refresh keptn#6085
• CLI: Update documentation  keptn#6086

Core

• Core: Mark APIs as internal keptn#6303
• Core: Don't expose internal API endpoints keptn#6302

Distributor

• Distributor: add support for client credential oauth flow for remote execution plane keptn#6728

Docs

• Core: RBAC add FF and document scope proposal keptn#7216

Resources

• https://datatracker.ietf.org/doc/html/rfc6749
• https://openid.net/specs/openid-connect-core-1_0.html
• https://auth0.com/docs/

[hwinkel]

Is there a option to Split this up into different Issues, Deliverables? i.e. for us the missing oAuth2/OPenID support is the most blocking issue to roll out keptn in the organization. Propagation of Authorization Parameters and RBAC Enforcement is nice, but especially proper RBAC Enforcement inside might take a while?

Proposed Split:

1. OpenID Auth Support toward e.g. keycloak, Github, Google, Microsoft IdP
2. Local Keptn Authorization READ, WRITE, Admin
3. Full RBAC Authorization Management inside keptn

[oleg-nenashev]

Status update: There is no ongoing work on KEP-60. I will move it back to refinement on the roadmap

[thisthat]

OIDC support for Keptn v1 is implemented.
Full RBAC support for Keptn v1 will not be provided. The TC decided to close this KEP.

[thschue]

TC decision: This KEP will not be implemented and therefore closed