Istio IstioCon 2021, 10 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Better External Authorization

Description

#IstioCon2021

Presented at IstioCon 2021 by Yangmin Zhu.

I will talk about the better external authorization feature in 1.9 that allows users to easily integrate Istio with external authorization system (e.g. OPA, OAuth2).

The better external authorization is the latest improvement that solves a much wanted customer request for better extensibility in the authorization policy.

This feature makes it possible and greatly improves the user experience of many critical use cases, for example, integrate with industry standard auth mechanism (e.g. OAuth2), reuse existing in-house auth system (e.g. OPA) and more.

A

Hey everyone. My name is yang min zhu, I'm a software engineer at google and eastern retainer, mainly working on the security side. I work a lot around the security policy. You may have already noticed so today. My talk is about the beta extra authorization.

A

So before we deep dive into today's topic, let's ask a simple question: what is extra authorization, and why would you even want to care about it?

A

Ex-Authorization, is to delegate the authorization decision to some custom logic that is not provided by istio.

A

So if you compare it with the eastern australian policy, the biggest difference here is that when you are using authorization policy, you only need to write the yaml file and the insta will take care of the remaining work like enforcing it, making the authorization decision based on your policy and when you are using the extra authorization.

A

It's you that you need to write the custom logic that actually enforce and inspect the request and make the authorization decision.

A

So why would you even need to use the extraordinary still is already providing the first class authorization policy? That's a very good question. There are a lot of answers here. I will just list some like most important use cases here, so we have found that many customers they need better extensibility in authorization to address those following issues.

A

First, for example, you may have your in-house authorization system that is developed many years ago and accumulated a lot of legacy code policy infrastructure over the years and all those things they just cannot be simply replaced by easter authorization.

A

There might be another case that you just want to integrate with some third-party solution, for example the open policy agent or oprah for short, and you have writing some like oprah policy and you don't feel comfortable or you don't have just you just don't have the resource or time to migrate to those opera policy to, for example, install authorization and you want to keep using oppa, or maybe you want to integrate with this os 2-proxy project, which is an awesome project that provides integration with a lot of os 2 providers, and you just want to use it with istio the last, but last list you may want to.

A

You may find that it's your authorization policy. It just lacks some like necessary semantics for your use case. You do not need very fancy logic, but the specific expression is not available in the easter authorizing policy. Yet all of these use cases- and the list goes on it- will bring you to this point that you need better accessibility in easter, australian policy.

A

So, okay, we understand the motivation here.

A

Let's take a look at what it is, how it is been down before 1.9 and what are the pain points of the old approach for the external authorization so before window 9, it is usually solved by using the roa xlrc filter, combined with the install our filter api and it of course works. But it comes with some big pain points here.

A

If you have used only api with xoc filter before I'm pretty sure you already know what I am going to see, and there are a lot of issues here. uh First, let's look at the usability onward. Filter is a very flexible and a powerful api.

A

It allows you to do a lot of low-level modifications to the outfit config that is generated by istio, but on the other side it is also very easy to make mistakes with always filter.

A

For example, you may have a mistyped url in the audio filter filter config that just causes not ending the filter correctly.

A

Another example is, you may want to use our filter to merge the bool value, and then you suddenly find out it's not working. The way you may want, last but not least onward filter is a breaking class low level api. That means improper use of the amplified api. It could easily crash your s2d.

A

Second, let's look at the maintenability problem of using our filter, so our filter api is generally hard to maintain and the situation becomes worse in some specific cases.

A

So, when you are writing on the filter, you are now reading using easter api. You are writing the roa config directly, which means you are using the roa api directly in istio. So that means any android. Api change could silently break your onward filter api without prior notice, because that is a transparent api in istio. We cannot really do a lot of validation against it to istio. It's it's something like a transparent config that we just passed to the runway and we cannot make sure it is always consistent with our version we are using.

A

So it's the user's responsibility to make sure that the outward version used in istio is consistent with the how we config that you specified in your rv filter, and sometimes you will even need slightly different rv filter in each different install version due to the alveolar filter. Api itself is like a changing rapidly. It's still alpha api, and this becomes worse. If you have a lot of unbuilt filter api applied in your large cluster and very hard to maintain and scale.

A

The third problem here is about troubleshooting.

A

This is specific to the extraordinary use case, because you are writing the xlrc config and due to the spatial use case of xor or ci config, it has too much low level details that you should take care of, for example, I will just give you one example here: if you are using grpc with your extra oc filter config.

A

The very first thing you need to specify is you need to figure out the cluster name that should be put into the xlrc field config, however, the cluster name and its format. So here is an example that.

A

Like this example, it has this outbound pipe, the port number and an empty string, and then a pipe and as another show my slim. So this whole cluster name. It is an istio internal implementation detail.

A

This means it could be changed anytime by e-still, because that's not an api at all and what's worse, if you need another, you would need another one: api, our filter api, to rename this into the class name, so that it does not include the pipe character because by default the external oc filter will use that classroom as the grpc request host header and in the hospital.

A

The pipe character is invalid and it will be rejected in the http connection level.

A

This is mitigated by another field that is added to the unveil, xlc filter, config, and that allows you to override to use a separate uh host header so that it doesn't default to use the class name. But before that is available, you have to apply some like a very handy, vocal round to use a second away filter to patch that hostname, so that it doesn't include the pipe character.

A

Last it's about the feature-wise.

A

So when you are using x or c, there is no way to trigger the extract flow conditionally and will, technically speaking, there is a way to enable or disable the xlrc using the per route configuration.

A

But if you are using our filter api that will be extremely difficult to use, because now you are not only modifying the field config. You have also need to mess up with easter bros configuration, which is a very complicated thing that I have not seen people doing it correctly so far.

A

This means you cannot really enable or disable the extra oscillator flow for a specific route based on things like pass, host, ip etc.

A

This is actually a very common use case for xoc, as well as for other, like authentication authorization.

A

Sometimes you just do not need to export say for things like health check, so you want to skip the exorcism for some health check and you cannot do that with old approach using our filter api.

A

So this needs goes on and on- and I think if you have looked at some other presentation in this istio khan, you will find that there are a lot of people. There are things that the difficulties they are using uh on will filter, but let's make it very clear, I'm not saying that you should never use onward filter api, the unrefield api, it's it's! It's very useful and it has its legit use cases.

A

But here is a big, but it is not the proper api that you should use for critical security feature in your production, environment and skill because of the usability maintainability and troubleshooting and the feature wise. All those things makes it not a proper like api that it should depend on for your production usage.

A

So this really comes to the question that we really need a better first class support of this extra oc, or we put it more general that we need a better support for extensibility in the authorization policy.

A

And you got it, that's what we are doing in insta109, we hear the user request, we hear the user complaints and we hear then and that's the result. We really focus on the authorization extensibility.

A

We are providing infrastructure level and first class api support of a better extensibility in the easter authorization policy. So here I will just focus on the two biggest changes in this feature. You will find more details. I will provide a link later in the slide to the original design dock, but here I will just focus those two things here.

A

The very first change is that we now have ended this custom action in the authorization policy. It allows you to specify where and when to trigger the extra oc service and in this authorization policy you will also need to refer to the extension provider by its unique name.

A

So talking about the extension provider, that's the second biggest change. We are making to support the extensibility here. We have added this extension provider concept in the mesh config to allow you to specify where and how to talk to the extraoc service.

A

So each extension provider has its unique name and it will be referred to by the authorization policy, and currently we support the extension provider of type away external oc filter. So you can see the our extra oc filter is actually a concrete example of like a using with easter authorization policy to demonstrate the extensibility.

A

And let's look into the api example, and we can show you here: the left side is a very normal authorization policy. You can see, we give it a kind. This alteration policy we give it a name extra or z, and we put it in the is still system namespace and it is using this selector to select the ingress gateway.

A

And here then it comes to the new changes we are adding in 1.9. We have this action that is called custom. This custom action will allows you to indicate the authorization check to this provider identified by this unique name. Here I give it name like my extra oc service and this action is triggered under these rules.

A

So this specific road means it will be triggered for request pass. If the pass has the prefix stash of the mean snatch, we are using the star one card in the end of the string to denote this is a prefix matching, and this rules is exactly the same rules that you might already be using in your existing observation policy, so there's really delta here.

A

Is this like a custom action and this simple provider with a simple string name, we are intentionally making this the same design decision to make it simple that you don't need to worry too much about in your ocean policy. That's basically just two fields you need to take care of, and then let's take a look into the extension provider on the right side.

A

So currently this extension provider is defined in the mesh config. For the current stage of this feature you can see we have this extension providers field. It is a list, so you can define multiple extinction provider and you can use just one of them at a time or you can use many of them.

A

Let's look at this specific extension provider, so here you see the name again. It has this name, my excel oc service, which should be used by the authorization policy you can see. We are referring to this name in the authorization policy and then it goes to the type of the extension provider.

A

As I mentioned earlier, we supported two types. For now. The first type is the roa extra oc using http interface. The other type is envoy extra occ using grpc interface. It's pretty much the same as this one, but with some other detailed configuration. So let's take and take a look at this example.

A

We simply give it a service name. Here I give it this xlc dot, food or service to cluster local. This means I have deployed my xoc server in the full name space and it is serving the xlc check. Request on port 8000 and design comes with some detailed configuration of the android oc filter for things like what should be sent to the xoc service.

A

What should be sent to the upstream backend here, I'm only using one configuration that we should include this header when we are sending the request to the xlrc.

A

So, combining those things together, that's basically all the things you need to use the extra oc in istio 1.9, you define the you define the xlrc provider in the mesh config. You refer it in your oscillation policy and in your authorization policy most fields. They are exactly the same as you are already using them before you don't need to learn a new matching rule.

A

It's the same authorization matching rule that should make it easier to adopt in your use case, and if you want to customize your hrc, you can put it in this extension provider, for things like include, the header in check include the header in like a back end. Things like that. You can also customize like as a the status returned by the xrc when it failed the check.

A

We pretty much provide almost all the configuration that you will find in the native xlrc filter itself.

A

So, let's, let's take a look at the architecture of how this, how like every piece of this configuration fits together.

A

So, first of all, you apply that authorization policy and you configure the extension provider in the mesh config easterd will then configure will will find your configuration. It will process your configuration and then it will distribute the alway config to the workload selected by your oscillation policy, which is a corresponding xlr oc field config.

A

So at this point you have already deployed the xoc filter to the hour inside the car without using onward filter api at all.

A

Then, let's look into the runtime behavior in the runtime. A request hits your font and service, and then it will be checked against the authorization policy if it is matched with the authorization policy.

A

For example, if you have this alternating policy, if the request it indeed has a slash admin snatch prefix in their pass, it will trigger the extra oc flow, and in this case the xoc filter will make a auth check to your extra os service, and this explosive survives will be hosted at this service.

A

At this point that handles that extra oc check.

A

Inside your xlr service, it will do whatever it needs to do to process the request and make the access control decision that the decision could be either a now or delay. If that is a delight decision, the request here, it will be delight immediately without further processing.

A

If that request is on allow from the extra rcc, the request will still need to conti. It will still need to continue to go through the other authorization policy that you may have applied in the front service in your sonic car.

A

So that basically means if you have custom action, delight action and allow action all applied. At the same time for the side car, the request will be denied if any of that action delivers and it will be allowed if all of them allow the request.

A

So after it is really allowed, we will just continue forwarding the request to the backend and your banking will process the request and is used to be so that's basically the whole flow of integrating the xlrc servers into istio.

A

Okay, so let's take a look at the benefits of this flow. First of all, you probably have already noticed that there is no more of a filter at all. The only api you need to configure is the authorization api and a small configuration in the mesh config to define your xlrc provider.

A

This is much easier used and simpler for troubleshooting, because you no longer need to deal with all those, unlike angry filter, low level details. Second, and more importantly, this is a first class api support from istio. It is much more reliable and stable.

A

That means changes in our way. You will not break your configuration in sql, because, technically speaking, you are not using onward api at all. You are now using easter api and esto will handle all those changes behind the scene automatically for you, because we will maintain the stability in the easter api and the easter api is supposed to be used by the end user, which is different from the output api that is supposed to be used by machine instead of a human being.

A

The second biggest benefit here is that the syn configuration will work stably during upgrades in different easter versions.

A

Well, strictly speaking, this feature is new in 1.9, it is still experimental stage, so we may still experience some changes based on useful feedback and until we promote this to alpha and the beta, but that will be the direction of this api and once it stays beta, we will have a strict and strong backward compatibility support last.

A

This api is part of the authorization api and it is well tested, maintained and supported by the install team. That's a another big benefit. If you are planning to integrate this skill with extra authorization that simplifies the input that simplifies the integration part so that you can focus on your xlrc part instead of the integration part last. It also provide you a very nice feature that it allows triggering the extra oscillator flow conditionally.

A

So now you can see something like only trigger the extra flow for host like example.com or only trigger the uh or or trigger the pass for uh triggers the extra zero for all paths except to the snaz health. You may have this slash. Health as a any point that you want, everyone has access to it, and you can do many similar things here.

A

Okay, so I have include all those important information about this feature in this slide. I will also share this slide to to the easter community. Once this presentation is done, you can find the original design dock. You need to join the easter team driver access for access to the design dock, that's a very detailed design tool that includes all those design decisions we made the trade-offs we made while we are doing it like today and implementation details pretty much everything about this feature.

A

You can also find the very useful and user documentation. We have published a blog post for this feature and it gives you an example, integration with oppa, which I will soon demo after this slide, and you can also look into the task page for using the custom action.

A

It shows you how to integrate with a sample xl server. That is also implemented as a part of sample server in istio. You can use that as a starting point to plug in your customer logic and and push it to your production, and if you are interested in the api, you can directly look into the formal protobuf definition of the api for both the custom action and the extension provider and last but not least, and actually very important. We really appreciate your feedback.

A

Please really, really. Let us know your thoughts, your suggestions on this.

A

We are working hard and we are working continuously to improve it in the 40 releases, and this is a perfect time to provide your feedback and if you want to see some changes in the api or if you want to see some features to be supported by this use case, because currently we are still at the experiment stage, as it gives us a lot of the opportunity to improve this api without worrying too much about the compatibility issue so feel free to provide your suggestions either in disclosure style or file, an issue in our github, and I thank you so much in advance.

A

Next, I will give you a demo of using this extensibility, so this new api in 1.9 allows you to integrate with many extra oc solutions like oppa, like os2 proxy, and I think it's very important to mention the difference here that when you are using oppa, os2 proxy or any other things, those things are also scope of istio. They are largely.

A

They are not maintained by easter itself. Here we are just providing the infrastructure label support, but it makes your life much easier to integrate with your like astro oc solution.

A

But please remember if you find any bugs in your like extra association, you should file your box against your extra solution instead of still, but if you find anything like regarding the integration parts, that part should that can go to you istio and it will handle that properly.

A

Okay. So let's look at this demo, so uh I will deploy opa in the default namespace as the extension provider in in the user case. It is usually maintained by the customer and in the eastern mesh. I will deploy the workload and with easter proxy and I will use oscillation policy to delegate the authorization check to the opa port.

A

Okay, let me switch to the terminal and to show you the demo.

A

By the way, if you look at the blog post, we actually have the full detailed instructions for integrating with opa as an example.

A

Okay, let me just show you some basic status in my kubernetes cluster. You can see. I have already deployed the example http being the example at sleep, that's just the example sleep and hdb. You will find in every steel task, and I have already deployed this oppa in the easter cluster. You can see it has two container, which means it has the istio proxy injected.

A

Let's take a closer look at it.

A

Yeah you can see we are using still 1.9, the proxy is injected correctly and we are using the latest oper that that is specifically built for the roa integration, because you are using oper. We also need to deploy and create the opera policy, and currently I have deployed this as a secret. In my cluster you can see there is a opa policy secret, not that is just an example of a policy that I deployed for the customized logic of access control.

A

Let's take a look at its content here, let's copy out this basis for encoded string and decode, it.

A

Okay, here you can see we have a example of a policy. It does sound like a custom processing of the george token, in the request check his fields and compare it against another field. In the john token, this customization country is not supported by easter australian policy. That's one of the reasons you may want to use oppa naked for things like this.

A

Now, let's start to enable the integration with this opera. Before we do that, let's confirm that our sleep pod is able to talk to our http pin port. So you can see for the three request. We are all receiving 200 hdb response code. That means we are not using the oppa at all.

A

As you remember, the very first thing we need to do is to define this extension provider. We need to tell the istio that hey, we want to use this extension provider, and here is a detailed information. That's how you can talk to that extension provider, so I will configure the istio config map to end this definition.

A

A

I can just add it here.

A

And then save and exit normally, it still will pick up the changes in the mesh config automatically after, like a one or two minutes, it's a bit slow because we are using. We are mounting the secret instead of watching a web mounting the config map instead of watching the config map. So to make things faster, I will just restart the.

A

A

But in your use case you don't necessarily need to restart your svg. You can just like wait, maybe one or two minutes to get it updated and if we later improve this study to use the watch api, it should uh find this change much faster, maybe like under 10 seconds.

A

Okay, the new study is now up and running, and then we can just apply the authorization policy before we do that. Let's take a quick look at the content of the authorization policy you can see. We are applying it to the http being workload because we want to enforce the access control for the http workload.

A

We are giving it to the custom action so that it will dedicate the oscillation check to the opaque container, and here we are using the extension provider that is called oper.default.

A

If you remember that's the extension provider, we added to damage config and we want to trigger this xoc flow. If the request path is not slash ip, you can think of this slash ip as some like a health check endpoint that do not need to be protected by the extra aussie.

A

So let's just apply this okay, it's applied.

A

Usually it will take a a few seconds for the policy to propagate. So let's try to send the request first to say: if it is already applied, it's not a it's not applied. Yet name is requested again. Okay, it's loud taking effective. Let's take a closer look at the first request.

A

The first request is that we are sending a request to this pass, slash haters from the sleep part, and we are not attention in the job token, and then you can see we are getting this 403, because oppa is rejecting the request.

A

Second, we send requests from the same sleeper part to the same slash headers, but this time we use a spatial token that will be accepted by oppa, and then you can see we receive this 200.. This is returned by because oppa allows this request.

A

Last we are sending again a request from the sleep report to the http, but enter different paths as the past ip. Without the authorization token you can say we don't specify the oscillation token like here and it is still allowed.

A

This is because we specified as a not pass ip, which means the request it doesn't even trigger the extra ocd at all. Oppa does not say this request at all, because we don't want it to trigger the extra flow and we can check the logs in the op-up container to confirm to confirm that it is actually enforcing all those.

A

A

A

A

You can see it's a little bit harder to see. So let me just search this.

A

And pass it to jq.

A

So if you have, if you have used oppa before you might be already familiar with this decision log, this is a log printed by oppa when it is making a access control decision about a request. You can see it has this unique decision id and from this input you can see the request inspected by oppa.

A

It is a request sent to this destination that has this http being from this source. That has this sleep principle. So oppa knows this request is from sleep to http, which has this past snatch headers, but it doesn't have this authorization header, so it gives a decision that it should be delight. The result is a force for the second request to snatch headers. It has this authorizing header and then is giving this decision a law result.

A

True, that's the only true decision made by oppa, which also proves that it is not seeing the request for the past to slash ip.

A

Okay, that's pretty much all the demo of the of using the oppa with this uh extensibility in easter 1.9. As you can see, you only need to configure the mesh config and then apply the authorization.

A

A

So, thank you. That's pretty much all from my side and uh thank you for your time and uh we look forward for your feedback and associations on this.

A