Skip to content

Access Control

Maira allows you to interact with all your cloud services. This presents Maira with an opportunity and responsibility to provide a unified access control over all these services. Maira's implementation comes with many other advantages as well.

Challenge

Usually, every cloud application has some sort of access control. This scattered implementation presents challenges to the Ops team. These problems include, but are not limited to:

  • Scattered access control that needs to be configured separately for each application. E.g. if you are running GKE on GCP, Kubernetes has its own access control and Google Cloud has its own that need to be managed independently
  • Some applications don't have granular enough access control
  • Some of these implementations are too complex to configure
  • Most of them do not allow you to grant access for a specified amount of time or based on location

Maira Solution

Please see the picture below to understand Maira object model for users and resources.

Maira Object Model

In Maira model, each user belongs to one or more groups and has a role (admin/member) in that group. E.g., user alice could have admin role in group engineering and member role in group test. You can grant access to either an individual user, or all users with a specific role in a group or all users in a group. Resources are identified by an object type along with an object name or id. Some objects can belong to a namespace. And they belong to a service, which itself can be identified by a service type and service name. E.g. A k8s pod has a pod name. It has type pod and it belongs to a namespace. It is part of service k8s and if you have more than one k8s clusters, then you identify the cluster using the cluster name. While granting access, you can specify what all actions (create/read/update/delete) are allowed.

Think of granting access as equivalent to drawing an edge between the subject and object in the above picture. E.g. an edge between the group engineering and the service type kafka with a label R implies that all users belonging to engineering group have read access to all kafka resources. Similarly, an edge between user alice and topic t1 with label CRUD implies that the user alice has CRUD access to that specific topic only.

Configuration

Maira dashboard allows you to assign users to one or more groups with one of the supported roles. After that, you can define Access Policy Rules that define who can access what. Please refer to the screenshot below for details on how to configure access policy rules.

Access Policy Rule

You can select a specific user, or a group with an optional role. On the resource side, you can select a service type, instance, namespace, object type and object id. Leaving any field empty implies all. E.g. If no object id is specified, then all objects of that type will be allowed.

Each rule also includes a field called decision. This can take allow/deny values and it indicates whether the command being accessed is to be allowed or not.

Implementation

When a user issues a command, Maira will identify all rules that connect that user to the resource being used in the command and the action being performed. To find the list of applicable rules, Maira will walk the hierarchy of user/resource and collect all rules. Only if all these rules have the decision set to allow, the command will be permitted. If any rule has the decision set to deny or no matching rule is found, then the command will be denied.

Each maira command has a defined action, service type and object type. Service instance, namespace (if applicable) and object id can be specified using one of the arguments for the command. Please refer to documentation to specific command if you want to see these values for a given command. As an example, for k8s get-pod command, service type is k8s, object type is pod and actions is read. Service instance is specified with the cluster argument, Object type is specified using name argument and namespace is specified using namespace argument. E.g. if a user issues k8s get-pod --namespace "ns-1" "pod-1", she must have read access to pod pod-1 in namespace ns-1 in default k8s cluster.

Maira's implementation is based on Next Gen Access Control12 proposed by NIST (National Institute of Standards and Technology) and provides full flexibility without the problem of role explosion that is typically seen with many RBAC implementations.

It is powered by Open Policy Agents (OPA), which powers the access control implementations of many cloud based services including Kubernetes. We define parametrized policies in OPA's policy language called Rego that is evaluated along with the policied defined by the user to decide whether access to a resource is to be granted or not in real time.

Upcoming Features

In upcoming releases, Maira will implement two more dimensions of the access policy rule.i

  • Location based rules: Each service and each user/group can have a location associated with it. Then a rule can specify a connection between a user's location and resource's location.
  • Time based rules: These rules will allow you to specify a time at which access is to be granted. This could be a one time grant or a periodic grant.

  1. https://www.tetrate.io/blog/rbac-vs-abac-vs-ngac/ ↩

  2. https://speakerdeck.com/nacx/next-generation-access-control-ngac-for-the-multi-cloud-world ↩