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.
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
Please see the picture below to understand Maira object model for users and resources.
In Maira model, each user belongs to one or more groups and has a role (
member) in that group. E.g., user alice could have
admin role in group
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 (
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
topic t1 with label
CRUD implies that the user
CRUD access to that specific topic only.
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.
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
deny values and it indicates whether the command being accessed is to be allowed or not.
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
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.
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.