{"id":1545,"date":"2023-09-01T07:50:07","date_gmt":"2023-09-01T07:50:07","guid":{"rendered":"https:\/\/imesh.ai\/blog\/?p=1545"},"modified":"2023-09-05T05:16:56","modified_gmt":"2023-09-05T05:16:56","slug":"implementing-stronger-rbac-and-multitenancy-in-kubernetes-using-istio","status":"publish","type":"post","link":"https:\/\/imesh.ai\/blog\/implementing-stronger-rbac-and-multitenancy-in-kubernetes-using-istio\/","title":{"rendered":"Implementing stronger RBAC and Multitenancy in Kubernetes using Istio"},"content":{"rendered":"\n

Background of multi tenancy <\/h2>\n\n\n\n

DevOps and solution architects often implement RBAC and multitenancy in their Kubernetes infrastructure to achieve isolation of workspace and allow authorized persons to access resources with least privilege resources. <\/p>\n\n\n\n

The implementation of RBAC and multitenancy can be very simple or complicated, and this depends of the following parameters:<\/p>\n\n\n\n

    \n
  1. Application- microservice based architecture<\/li>\n\n\n\n
  2. Deployment speed & frequency- High or low<\/li>\n\n\n\n
  3. Architecture- Multi-cloud cloud\/Hybrid cloud\/ On-prem <\/li>\n\n\n\n
  4. Environment- Dev\/stage\/prod<\/li>\n\n\n\n
  5. Teams\/Groups- Developers, DevOps, SREs, Marketing\/Pre-sales<\/li>\n\n\n\n
  6. Users- application developer, full stack developer, web-API engineer<\/li>\n\n\n\n
  7. Budget in hand<\/li>\n\n\n\n
  8. Goal- Simple administration vs granular security <\/li>\n\n\n\n
  9. Geography team- Multi-geo<\/li>\n<\/ol>\n\n\n\n

    In this article we will discuss how to implement RBAC and multitenancy (simple or complicated) in Kubernetes using open source Istio service mesh<\/a>. <\/p>\n\n\n\n

    Enabling RBAC for K8s service accounts and users using K8s resources<\/h2>\n\n\n\n

    We have discussed at length about how to enable Kubernetes RBAC<\/a> using various resources such as- Role<\/em><\/strong>, <\/em>ClusterRole<\/em><\/strong>, <\/em>RoleBinding<\/em><\/strong>, <\/em>ClusterRoleBinding<\/em><\/strong>. The idea of using all the Kubernetes RBAC resources is to create various actions that can be taken on namespaces or resources and then allocate (or bind) the actions to users and service accounts. To restrict IPs i.e. ingress and egress traffic, network policy resources (refer the image below) in Kubernetes can be used.\u00a0<\/p>\n\n\n\n

    apiVersion: networking.k8s.io\/v1\r\nkind: NetworkPolicy\r\nmetadata:\r\n  name: banking-network-policy\r\n  namespace: dev-namespace\r\nspec:\r\n  podSelector:\r\n    matchLabels:\r\n      role: db\r\n  policyTypes:\r\n    - Ingress\r\n    - Egress\r\n  ingress:\r\n    - from:\r\n        - ipBlock:\r\n            cidr: 172.17.0.0\/16\r\n            except:\r\n              - 172.17.1.0\/24\r\n  egress:\r\n    - to:\r\n        - ipBlock:\r\n            cidr: 10.0.0.0\/24\r\n      ports:\r\n        - protocol: TCP\r\n          port: 5978<\/code><\/pre>\n\n\n\n
    However, there can be certain limitations of using K8s RBAC.<\/p>\n\n\n\n
    Limitations of using Kubernetes RBAC for workloads and services<\/h3>\n\n\n\n
    You see, the Kubernetes RBAC is good for implementing users’ access to certain resources by applying checks on API servers. It is very good when you want to allow developers to perform experiments on a cluster or a namespace or testers to deploy services and test in testing workspaces. <\/p>\n\n\n\n
    But what about authorization of workloads or services? How to implement granular controls to workload authorization in production environments. Some of the limitations are: <\/p>\n\n\n\n
      \n
    1. K8s RBAC is challenging to implement for granular usage. Imagine you want to restrict accounts to use few resources in an endpoint (a service in a namespace) or want to control REST operations on the pods, K8s RBAC will not be sufficient in this case. <\/li>\n\n\n\n
    2. Difficult to create RBAC policies in Roles and RoleBinding. For e.g. in a large organization there can be multiple clusters and namespaces. There can be 100+ services running in all these namespaces and is handled by various application teams. And many of these services need to talk to each other. DevOps may end up creating too many Roles, RoleBinding, ClusterRoles, and ClusterRoleBinding objects. <\/li>\n\n\n\n
    3. Similarly in large set up updating and deleting an RBAC policy in the Kubernetes resource can also be daunting. <\/li>\n\n\n\n
    4. For ingress and egress traffic (or east-west and north-south traffic) one has to create additional Network policies along with Kubernetes RBAC. <\/li>\n<\/ol>\n\n\n\n
      To make the RBAC implementation simple, Istio can be used. <\/p>\n\n\n\n
      Note: It is not Kubernetes RBAC vs Istio<\/strong>, but Kubernetes RBAC and Istio<\/strong> for better manageability and implementation of RBAC and multitenancy for users and production workloads. <\/p>\n\n\n\n
      Achieving RBAC multitenancy with Istio<\/h2>\n\n\n\n
      In case you are using Istio for simplifying your network, security or observability you can use Istio service mesh for implementing RBAC and multitenancy in your Kuberntes workloads and for your teams. <\/p>\n\n\n\n
      Note: The approach of Kubernetes RBAC is user-first i.e. defining what user can do what operations. But Istio uses the resource-first approach i.e. it dictates who can do what on a particular service (and its resources). The advantage of Istio\u2019s approach is manageability of the RBAC and multitenancy rules (we will see later in this article) with its Authorization policy<\/a>.<\/p>\n\n\n\n
      There can be multiple easy-to-complicated scenarios where Istio can be used to implement RBAC:<\/p>\n\n\n\n
        \n
      1. Single cluster-multiple namespace<\/li>\n\n\n\n
      2. Multicluster-multiple namespaces<\/li>\n\n\n\n
      3. Multicloud- multiple cluster (multiple namespace)<\/li>\n<\/ol>\n\n\n\n
        We will look into each scenario and understand how Istio can be used for RBAC and multi-tenancy. <\/p>\n\n\n\n
        Scenario1: RBAC for single cluster-multiple namespace using Istio<\/h3>\n\n\n\n
        Let us take an example where there are multiple namespaces for various non-prod environments which have to be shared among developers and Devops. In the image below, we have dev-namspace and staging-namepsace where a banking application with multiple services are deployed. And each namespace will be allowed the editing rights to certain team members. The banking application contains 3 services- profile, transactions and account-summary- they talk to each other and share data. <\/p>\n\n\n
        \n
        \"RBAC<\/figure>\n<\/div>\n\n\n
        One can achieve isolation of workspace and allow least privilege access to team members using Kubernetes RBAC- i.e. through defining Role and RoleBinding, and workloads authorization can be implemented using Istio Authorization policy ( sample below):<\/p>\n\n\n\n
        apiVersion: security.istio.io\/v1beta1\r\nkind: AuthorizationPolicy\r\nmetadata:\r\n  name: restrict-access-policy  namespace: stage-ns\r\nspec:\r\n  selector:\r\n    matchLabels:\r\n      app: account-summary\r\n  action: ALLOW\r\n  rules:\r\n  - from:\r\n    - source:\r\n        principals: [\"cluster.local\/ns\/stage-ns\/sa\/profile\",\"cluster.local\/ns\/stage-ns\/sa\/transaction\" ]\r\n    - source:\r\n        namespaces: [\"dev-namespace\"]\r\n    to:\r\n    - operation:\r\n        methods: [\"GET\",\"PUT\",\"POST\"]<\/code><\/pre>\n\n\n\n
        The best part is that as the network and security is abstracted from the application using Istio service mesh, it is easy to implement and modify authorization policies or rules. The above Authorization policy in Istio is implemented to side-car proxies which will validate any REST API request to any workloads. <\/p>\n\n\n\n
        In case you have an end-point for a microservices and there are many resources to be used; for e.g. account-summary <\/strong>microservice has 2 resources i.e. current-year <\/strong>and previous-year <\/strong>for getting the account summary for current year or\u00a0 previous year. In that case, you can use path (or URI) in the Istio Authorization policy. Check the sample Istio Authorization policy below.\u00a0<\/p>\n\n\n\n
        apiVersion: security.istio.io\/v1beta1\nkind: AuthorizationPolicy\nmetadata:\n\u00a0 name: account-summary\n\u00a0 namespace: staging-ns\nspec:\n\u00a0 action: ALLOW\n\u00a0 rules:\n\u00a0 - from:\n\u00a0 \u00a0 - source:\n\u00a0 \u00a0 \u00a0 \u00a0 principals: [\"cluster.local\/ns\/stage-ns\/sa\/profile\"]\n\u00a0 \u00a0 - source:\n\u00a0 \u00a0 \u00a0 \u00a0 namespaces: [\"staging-ns\"]\n\u00a0 \u00a0 to:\n\u00a0 \u00a0 - operation:\n\u00a0 \u00a0 \u00a0 \u00a0 methods: [\"GET\"]\n\u00a0 \u00a0 \u00a0 \u00a0 paths: [\"\/previous-year\", \"\/current-year\"]<\/code><\/pre>\n\n\n\n
        Note, this is just a few use-cases, you can apply any RBAC use-cases to services using Istio. The Istio Authorization policy provides various actions such as ALLOW,  DENY, CUSTOM that can be applied to any workloads for the REST calls. Read more about Istio Authorization policy<\/a>.<\/p>\n\n\n\n
        You can also watch the video on how to set up RBAC and multitenancy using Istio service mesh.\u00a0<\/p>\n\n\n\n
        \n