Cloud Native Computing Foundation Production Identity Day: SPIFFE + SPIRE 2020, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Fortifying Microservice Security with SPIRE and OPA - Ash Nakar

Description

Fortifying Microservice Security with SPIRE and OPA - Ash Nakar

Microservice architecture although beneficial brings with it unique security challenges around authentication and authorization which become more acute due to the diverse nature of microservice environments.
How do we reliably authenticate and authorize interactions between 10s, 100s, or even 1000s of services at scale while handling 1000 API calls per second?

SPIRE solves authentication by creating an identity plane across varied infrastructure over which cryptographically verifiable identities such as JWTs are delivered securely to workloads. OPA provides a policy engine that can be used to enforce fine-grained authorization policies across the stack.
We will show how SPIRE issued JWT SVID claims created using SPIRE’s OIDC Federation can be used by OPA to enforce service-to-service and end-user access control in microservice environments without compromising on speed and availability.

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.

A

uh So, thank you all for having me here today. My name is uh ash narker. I am a software engineer at styra and I'm one of the maintainers of the open policy agent and I care about developing secure software systems that can be readily deployed, scaled and managed, and we also have with us madhu.

B

Hey folks, uh I'm geshwali I've been part of spiffy inspire open source project. Almost since its inception, I today, I kind of like helped out ash with this demo. So that's the reason. I'm here.

A

Thanks madhu, uh so the agenda for the talk is I'll quickly. Do uh overview of the oppa project. Talk about its features, then madhu is going to talk about propagating user identity through john s, witz and finally, you'll see a demo of how spire and oppa are gonna work together for oidc federation.

A

So let's get started uh so just a quick intro of the oppa community. The project started in 2016 at styra, where I work and the goal of the project has been to unify policy enforcement across the stack. Opa has been used in production by many companies for cases like admission control, authorization, our back abac and so on.

A

It's a cncf project currently at the incubation level, hopefully we'll graduate soon, and it has more than 150 contributors on git, a healthy slack community of more than three thousand members, more than four thousand stars on git and it's integrated with more than 20 of the most popular open source projects out there, including spire istio, envoy, kubernetes and so on.

A

So what is oppa oppa, which is the open policy agent, is an open source. General purpose policy engine when you use oppa, you are decoupling the policy decision making from the policy enforcement, so your services can now offload queries to oppa for a policy decision.

A

So the way this typically works is that imagine you have a service, and this can be any service at all. It can be a kubernetes api server. It can be your own custom service, kafka onboard whatever. Whenever your service gets a request, it's going to ask oppa for a policy decision by executing a query.

A

Oppa is then going to evaluate that query based on the policy and data it has access to and send a decision back to your service where it gets enforced.

A

So you can see the decoupling happening here between the decision making and the enforcement.

A

The policy query itself can be any json value, so you can give oppa like the http request, method path, the user, if you're doing http authorization, if you're doing admission control, you can give oppa the entire pod manifest so give it some kind of structured data and oppa returns a policy decision which is again a json value back to you, your service for enforcement, a few of opa's features.

A

Real quick at the core of oppa is a high level decorative language called rego, which allows you to write policy decisions that are more than billion, basically any json value, arrays objects and so on, oppa's written in go and you can deploy it as a sidecar host level. Daemon, it's designed to be as lightweight as possible. So all the policies and data it needs for evaluation are stored in memory.

A

It provides some management apis which allow you to fetch policy and data from remote services. It can upload decision logs to remote services and also its status and finally, along with the core policy engine oppa provides a red set of tooling to build test and debug your policies. It provides a unit test framework as well as integrations with of ides like vs code intellij and the lego playground.

A

So now the transition to the demo part of the talk which we'll talk about in which we'll see how policy decisions are based on the user and service identity and madhu is going to do that demo for us live, but before we do that, I wanted to set up the demo for you.

A

So what we have? We have a acme healthcare which provides its members a platform to view invoices, and this platform is composed of three services: the front-end service, which allows members to log in and see their invoices an invoice service which holds the actual invoices.

A

And finally, we have a claim service, which holds the claims which are part of the invoice. So the way the demo is going to work is that you're going to have a user when the user logs in with the front-end service, the front-end service, is going to authenticate the user via an idp.

A

The idp returns a token back to the front-end service, which it then forwards to the invoice service. The invoice service then asks the claim service for the claims that will be part of those invoices.

A

So the claims are basically like a simple object which contain the status of the claim, the provider, the procedure and so on, and the invoice service will simply take that claims, object and embed it in the invoice object which looks simply like this and send it back to the front-end service, which will present it in a beautiful way for the user to consume.

A

So this is how the flow of the demo is and how this demo is going to work.

A

So next, the policy that we want to demo says that users with the role billing manager, can view claims in the invoices again the policy, the oppa policy that we will see in the demo says that users with the role billing manager, can view claims in these invoices and so to demo. This policy you're going to have couple of users. One is alice, and one is john, where alice is a billings manager and while john isn't enrolling, and we will see later how this information is being decoded from the george s.

A

Vids later on in this talk, but again so we have couple of users to help us with our demo, and so what you're going to see is that, when alice logs into the front end service to see her invoices, when the invoice service asks the claim service for the invoices, the claim service will ask oppa for a decision, and so the claim service is going to send oppa all the job tokens and all the jot s bids that it needs to make this decision.

A

Oppa is going to validate verify, decode those tokens and based on the claims it's going to make a decision on whether alice should see her claims or not and since alice is a billings manager. Oppa is going to allow this request to go through, and so alice will be able to see her invoices with the claims in them.

A

On the other hand, if john who's an enrollee, tries to see the claims, oppa is going to block this because uh john is an enrollee and therefore oppa will deny the decision, and what you all will see is that, although john can see the invoices, the claims will be empty.

A

So now I'm going to hand it over to madhu who's going to do a live demo real soon and before that he's going to talk about propagating user.

B

Identity to john.

A

S, wills madhu, take it over.

B

Yeah uh thanks ash so essentially.

A

B

Kind of interests me in this particular demo here is every time I talk to folks about identity.

B

The first thing that comes to mind is user identity right so, uh but uh really spyro.

A

Is not about that.

B

Aspire is about service authentication, providing identities to services. uh Earlier today, uh andrew jessup mentioned about having a working group which deals about delegated authentication, uh which talks about transitive identity.

B

We're still trying to frame that- and I kind of see this as one of the use cases why we need that why we need a delegated authentication or why we really need a transitive identity um kind of like a more generic use case for this demo is you have uh you want to have like a cascaded or a chaining of your identities, starting right from where the user authentication happened right?

B

uh Think of the front end here as an edge service that is running elsewhere, perhaps outside your infrastructure in this demo, this is going to be my laptop and you're, trying to authenticate the user using one of your idps, whether it's ping or octa, or something like that. That also gives you a jot token, and you propagate this jaw token, as part of your claim, a request that you're doing to your spire and you can think of right now. The only available claim with that is supported with inspire is the audience claim.

B

So I'm using uh so we are using the jar to switch to be part of that audience claim make that request and propagate all of this through why we are doing that is because at the open. So this is the application part. Why do we need the related authentication so at the application at the authorization server? That uber is you are able to integrate with the jocks uri and not only validate all of those chat, ass bits that are part of that chain, uh but also extract.

B

uh You know, like the actual claims of that all of this chain that happened right right from the user, to the service one to service n and at each individual level you you can possibly like uh validate those from the issuer itself right. So that's kind of the use case here. uh Let me share my screen here: real.

B

B

So uh in this demo uh we have, uh this is kind of the ui that is showing the actual uh deployment. So this is the kubernetes setup. We have individual name spaces pyro is deployed as uh inspire agents are deployed, as daemon set spyro is deployed as a stateful set and along with spire itself.

B

We also have, if you look at this um particular one. We also have uh the container the oidc provider right like so. The oedc discoverer is running alongside with the spire server itself, and we have deployed both the backend service and which has the actual data that is consumed and the invoice service is kind of like the ingress service. If I may call that which the front end is consuming right so uh over here on this terminal here I have alice, who is trying to log in to that application and.

B

I have been open this for quite some time here.

B

B

I'm trying to login.

A

B

Alice, who has a particular uh profile so, as uh we see here, we have this billing manager is the actual uh one of the properties. One of the claims within the javascript that was uh provided by octa and that particular user is validated, and this is the actual javascript that is coming. So we are seeing that oppa is allowing this particular request. So we are able to see the claims information here, but if I log in as the other user john here.

B

We should not be able to see.

B

B

So this is john. He has a different particular role and if we go to his particular dashboard and try to see the invoices, you see that the claims information again it's kind of like a overloaded term here claims in in the application. This is kind of like the insurance claims, not necessarily to do anything with the chart claims, but the jar token itself. You can see that uh opua denied information. So this data, the claims insurance claims data- is coming from the backend service and is denying access to that particular user there.

B

So if we actually take a look at this jot token here- and let me open this up a different window.

B

So you see that in the audience itself, so that was the information that is coming from uh the jot s, vid that was issued to the invoice service and this particular information audience itself is kind of like the chaining that I was mentioning. So itself is the chart that was issued by uh octa or the identity provider right.

B

So here we have the information so at the authorization oppa layer wherein we are making authorization decision, we are validating both the jar test, width and also, which is part of the audience claim, and also the actual javascript of the service itself, and even though the service has allowed, we have a policy which uh only which verifies both the service uh claim and also the user claim itself.

B

So, as you can see here, we have this embedded as a claim within that javascript and because we have the oidc federation that is done between the oppa authorization server and the spire server. We are able to like validate this and also. Similarly, we can also write a policy, the rego policy, which also can validate the octa chart itself, and uh we have this particular policy here and we are verifying both the token and also the actual claims within the user itself and making a decision based on both.

B

So yeah, that's that's the short demo there, I'm hoping to take any questions uh back to you. Ash.

A

Great thanks thanks madhu, so we do have a question so how granular can oppa control access, for example, in this demo? What if billings manager should be allowed to view certain claims and enroll you to view certain different claims? So that's a great question: uh we can definitely do granular access with oppa. Like I said you give it any kind of json value. Your policies can be as uh granular as you want to, and you can you like. It can decode your tokens like the job s word or any other token that we give it.

A

It can verify it using the jocks uri and then you can write pretty fine grain policies uh with that. So it's totally possible to do that.

A

I have one more question here: uh by najeeb: can oppa perform the static analysis of yaml manifest so yeah, so there is a separate project in the opa name. Space called contest, which is for validation of kubernetes, manifests and other kind of different files like docker files, so yeah check that project out and it can probably solve your use case.

A

uh One more question: by dennis we've created oppa policies for resources at the record level, definitely possible okay. So thanks thanks for validating that dennis I appreciate it yeah so again, thanks you all for uh inviting us for this talk for giving us the opportunity, if you have any questions we'll be here and thanks amaran team and this entire spiffy inspired team. Thank you. So much.