feat: Role, ClusterRole, RoleBinding, ClusterRoleBinding L2s

[Chriscbr]

Fixes #24
Fixes #25
Fixes #26
Fixes #374

Adds Role and ClusterRole L2s with "allowXxx" methods that resemble those available in the AWS CDK. This allows you to write code like:

import * as kplus from 'cdk8s-plus-23';

declare const deployment: kplus.Deployment;

const role = new kplus.ClusterRole(chart, 'my-cluster-role');
role.allowRead(deployment, kplus.ApiResource.SECRETS, kplus.ApiResource.PODS);

...where the "read" syntactic sugar grants permissions to the "get", "list", and "watch" commands. There are other allow commands available that offer more granularity if needed.

RoleBinding and ClusterRoleBinding L2s have also been created, and they can be instantiated through their constructors, or created using the appropriate bind methods that will attach it to the role automatically:

declare const role: kplus.Role;
declare const clusterRole: kplus.ClusterRole;

const user = new kplus.User({ name: 'alice@example.com' });
const group = new kplus.Group({ name: 'frontend-devs' });

role.bind(user, group); // creates a RoleBinding associated with the same namespace `role` was defined with
clusterRole.bindInNamespace('development', user, group); // creates a RoleBinding associated with namespace "development"
clusterRole.bind(user, group); // creates a ClusterRoleBinding, not associated with any namespace

Future work:

• Add full pod.grantRead(role) and Resources.fromTypes(ApiResource.POD).grantRead(role) style APIs
• Add type checking or validation to prevent adding namespaced resources to ClusterRole or cluster-wide resources to Role's etc.
• Add more constants to ApiResource for granting permissions to subresources
• Add convenience APIs for adding permissions to the default roles using aggregate-to-<default-role> tags

BREAKING CHANGE: The interface Resources is now named ContainerResources.

Signed-off-by: Christopher Rybicki rybickic@amazon.com

[iliapolo]

Suggestion for API:

const role = new Role(this, 'Role', { namespace: 'default'});
role.grantList(Grantee.fromObjects(deployment, pod));
role.grantList(Grantee.fromKind(Kind.Secrets, Kind.Deployments));
role.grantList({
  objects: [deployment, pod],
});
role.grantList({
  kinds: ['secrets', 'deployments'],
});

const binding = role.bind(user1, group1);
binding.addSubject(serviceAccount);

const role = new kplus.ClusterRole(chart, 'grafana-operator');
    role.addRule({
      apiGroups: [''],
      resources: ['events'],
      verbs: ['get', 'watch', 'list', 'create', 'delete', 'update', 'patch'],
    });
    role.addRule({
      apiGroups: ['integreatly.org'],
      resources: [
        'grafanadashboards',
        'grafanadatasources',
        'grafanadatasources/status',
      ],
      verbs: ['get', 'list', 'create', 'update', 'delete', 'deletecollection', 'watch'],
    });

Would be:

const role = new Role(this, 'Role');
role.grantGet(Kind.EVENTS);
role.grantWatch(Kind.EVENTS);
role.grantList(Kind.EVENTS);

role.grantGet(Kind.custom({ resources: 'grafanadashboards', 'grafanadatasources', apiGroup: 'integreatly.org'} 

[Chriscbr]

This isn't being used, since I designed ResourceType to implement IGrantee as is. Should I drop it?

[iliapolo]

@Chriscbr I think ApiResource is the eureka name we've been looking for! Good idea.

Both pods and a single pod named foo represent an ApiResource (i.e one that can be managed via the API) - Its just that one has a type, while the other has a name.

So, if we define a common interface:

export interface IApiResource {
  // mandatory, both pods and a single pod has this.
  readonly apiGroup: string;

  // optional - pods will have this
  readonly type?: string;

  // optional - a single will have this
  readonly name?: string;
}

Then, our Resource class actually already implements this interface.

export abstract class Resource extends Construct implements IResource, IApiResource {

If we now make ApiResource implement it:

export class ApiResource implements IApiResource {
  /**
   * API resource information for Binding.
   */
  public static readonly BINDING = new ApiResource({
    apiGroups: [''],
    resources: ['bindings'],
  });
  ....
  ....
}

We can change the allow methods to accept:

public allow(verbs: string[], ...resources: IApiResource[]): void {

And viola, we have the API we wanted:

role.allowRead(deployment, kplus.ApiResource.SECRETS, kplus.ApiResource.PODS);

Thoughts?

[Chriscbr]

Thanks for all of the feedback @iliapolo ! This should be ready for another review 🙂

[cdk8s-automation]

💔 All backports failed

Status	Branch	Result
❌	k8s-21/main	Backport failed because of merge conflicts
❌	k8s-20/main	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

backport --pr 432

Questions ?

Please refer to the Backport tool documentation

[iliapolo]

💚 All backports created successfully

Status	Branch	Result
✅	k8s-21/main

Questions ?

Please refer to the Backport tool documentation

[iliapolo]

💚 All backports created successfully

Status	Branch	Result
✅	k8s-20/main

Questions ?

Please refer to the Backport tool documentation