Cloud Native Computing Foundation KubeCon + CloudNativeCon China 2019 (Shanghai), 26 Jun 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Lightning Talk: How We Use Istio and OPA for Authorization - Lin Tao, HP

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Lightning Talk: How We Use Istio and OPA for Authorization - Lin Tao, HP

I'd like to introduce how we use istio + OPA to do authorization in HP's FitStation platform. Our project consists of 20+ micro-services which are written in Golang and running on Kubernetes with istio enabled. These services are divided into multiple layers and on each layer we apply different authorization via istio mixer and OPA. I'd like to give a high-level introduction on how we make this work, following topics will be covered: - how we leverage istio adapter to do authorization - how we integrate OPA into our micro-services - how we manage our OPA policies

https://sched.co/Nrrr

A

Hello, my name is Lin Tao I'm from HP today, I'm going to talk about how we use issue and open policy agent for authorization. So first I would like to talk about authorization. Other ization is to verify brand identity. Has the permission to do something, and there are many common approaches to do: authorization like load based access control, which you can tested by ropes. It is cost current. The typical example is kubernetes are back and there's also policy or attributes based access control, which you can access by policies.

A

It is more fine-grained typical example is a table as I am policies and we are using both of this purchasing our current project, so little background on our project is called a precision platform, which is a customer shoes. Iphone. We have many third-party partners developing their service on our platform using a platform API and the service built by these partners are running the same kubernetes cluster as our prep on services. So it's a challenge for the platform network, security and access control.

A

So we divide these services into layers, so we have layer 1 which our partner service and we have layer. 2, which are pipe on services- and there are three for internal services and on inch layer, we apply different authorization scheme. So in l1 we are enforcing road-based, as you can showing in for cha-cha layer. That's where it's your mixer comes in, so we have a customized audio adapter on the mixer. So all the requests to l1 service will be handled by our adapter. The adapter will authorize.

A

We are with our centralized authorization service and just all we config the adapter. We have rule basically says that only the request to the service with layer equals L, one will be handled by the adapter and here's the adapter template. It defines all the temple attributes from ICO that will be used by the adapter, so there definite what who is trying to access your API and then the adapter can authorize with our authorization service using our row base authorization.

A

So that's a one authorization, so we are basically checking if user is able to accessible API, it's consequent. But it's what we want in l1 services in l2, we have service from different partners and resource from different partners. We want more fine-grained access control so, for instance, the company a can cannot access company B's resources. So that's where open policy agent comes in, so we have library cards declined which are l to services are integrated with, so the this client will send the authorized request to open policy agents. So a little background on policy agent.

A

It's a general purpose authorizing engine from CN, CF I think it is just graduated and basically your service will send a query to open policy agent and open path. Agents will make authorization decision for you based on the policy and data you can pick so here's a typical example. So, in our order service we have other clients integrated and when, let's say the user Alice trying to request others from company HP, our client LT client will extract attributes from current request and packaging into a JSON payload.

A

So these attributes include user attributes and API attributes and request attributes and they will be sent to open policy agent and on the other side, open policy agent is complete with our policy and data. So this policy defines that our user is only able to access orders from his own company and the data here we define the relationship between the users and companies. So, with these three pieces of information, open policy agent is able to make authorization decision and return the result to our service.

A

So that's basically how we enforce the fine grain access control in our l2 services and here's the overview in a 1. We enforce the row base as control within semester and help you with a pack using open parts, agents and l3. It's all internal services. We are applying some network policies to limit access to the l2 services.

A

So thank you because the time is limited. I can step into details, but if you are interested, please feel free to reach out to me, I'll be happy to answer. Thank you.