Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2018 (Seattle), 16 Dec 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Athenz with Istio: Single Access Control Model in Cloud Infrastructures - Tatsuya Yano

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

Athenz with Istio: Single Access Control Model in Cloud Infrastructures - Tatsuya Yano, Yahoo Japan Corporation

Most Cloud computing environments are based on self-service thus authorization configurations are frequent and dynamic. Furthermore, in Microservices architecture, each service communicates via Web APIs thus it is important to have precise and frequently configurable access controls with low cost. Athenz is an open source platform for X.509 certificate based service authentication and fine-grained access control in dynamic infrastructures that provides options to run multi environments with a single access control model. We also plan to provide integration with SPIFFE and Istio. In this session, the speaker is going to explain the benefits of using Athenz and demonstrate how to use Athenz in a Cloud computing environment by showing use case of the integration with Istio. Website http://www.athenz.io

To Learn More: https://sched.co/GrZx

A

Hi everyone thank you for joining me today. Today, I'm going to talk about Athens with sto single access control model in cloud infrastructure, I'd like to start off by telling you about Athens and show how we use multi cloud in the Yahoo Japan then show benefits of using Athens with East EO.

A

My name is Tatyana I'm a platform developer in Yahoo Japan I've been contributing to Athens and having session in open source summit Japan. So if you and if anyone is interested, please visit the site first, what is Athens Athens is an open source system created by Yahoo Inc. It provides two major features. The first feature is service. Authentication Athens provides secure identities in the forum, short-lived x.509 certificate to any modern cloud environments.

A

The second feature is authorization. It provides fine-grained role based access control.

A

So, let's start from service authentication. When talking about authentication. There are two different principles: there are many easy standardized ways to do: user authentication like Active, Directory, LDAP, Kerberos or etc. However, we still don't have as many good solutions for service authentication. A service can be determined as many things like process application instance or host, for example, by using IP alcohols. The configuration will be more complex as the system scale by using headless user account. We have to register and manage each account. Another way to do this is to use share secrets.

A

However, this approach can be vulnerable to leakage of the secrets themselves. For example in man-in-the-middle attacks in multi cloud environments. The most common secure way is to use mutual TLS authentication with x.509 certificates by using search key based, authentication every instance or service in your cloud can have their own identities that allows them to communicate to each other securely by using metrio, TLS authentication.

A

Mutual TLS authentication enables us to securely identify the client and server on both sides, also in cloud modern cloud environments. Since our system can be sometimes built outside of our private networks, it's becoming more important not to just trust their access, but to verify every access before authorizing them in Athens we is short-lived search, gets to prevent the credential in case of leaks. The circuits will be expired in 30 days by default, and the distillation can be shortened with your security requirements.

A

Accordingly, using certificate based authentication can provide good security, but we still would have a remaining question. Then, how do we provision those circuits into our workloads?

A

Athens provides a generalized model to boost rapid certificates into each pod, or instance, by doing a call back based verification against authorized service providers. We call this model. Kapur Argus Athens also supports adding specie ID, which is a standardized format of identity in the Sam field of the certificates, so any product which can identify other services with speechy ID can be compatible with Athens.

A

This is the flow to do the bootstrap in copper argus model. First, on number one. The authorized principles try to launch the instance by contacting the provider on their cloud, then, on number two: the provider will generate an identity document that is signed by their own private key and identifies an instance. They boot then passes it to the instance on bootstrap, then, on number three Athens provides a client called SIA. Sia means service, identity agent that runs in each instance.

A

Cl generates its private key inside the instance, which never leads from assistant height and also generates a CSR from the private key that was created by itself.

A

Then, on number, four SIA will make a request against Athens server to register the instance. Information by passing the identity document, which was signed by the provider and also the CSR created by itself.

A

When Athens receives a request on number five, it will first verify if the provider Whitten in the identity document is authorized to launch the particular instance.

A

Then on number six, it will make a callback request to the provider to confirm if the identity document that was passed from the instance is valid and also the instance is managed by the provider.

A

Athens will report the instances IP address to provide a provider, so the provider can verify that the request is coming from the expected client.

A

Then, if the verification on the provider succeeds on number, seven Athens will make a request to a different component called certificate signer to ask for generating actual certificate.

A

When the surgical signer receives the request, we will talk to HSM hardware security module, which does the actual signing and generating a new certificate after Athens getting the search gift from certificate signer, it will send back it to the asia on number eight.

A

This is the flow to do boostrap in copper, argus model. The search kid issued in this flow is short-lived, so we don't need to manage your ELLs. Sia will also continue to run on the instance in order to refer to the certificates by following the same flow.

A

The second feature is to support authorization in order to do otter, ization in Athens I'd like to explain the four main words in Athens is data model. The first one is the main. The main is an namespace to seperate other entities into different scopes. Other entities will be defined under a specific domain.

A

The second one is principal principles can be users or services that are authenticated. Then we gather principals to roles. Every domain has admin role inside by default, and only the members of the admin role can modify the domains entity.

A

Lastly, we can create policies. Policy is a set of assertions that can be defined to grant or deny any particular action to a certain role on a specific resource.

A

By defining these entities on Athens, we can have a role based access control on any modern cloud environments with single source of truth, most infrastructures in cloud computing environments like kubernetes OpenStack, a bit AWS or other, have their own system of access control. But Athens provides interface to integrate with each infrastructure to run multi environments with a single access control model.

A

This is an example how we can register those on Athens Athens has a web UI, REST, API and CLI to configure any entities under the domains. In this example, domain Athens. First, we have the admin role by default and front-end role that the service Athens of instance, is a member of. Then we have policies. The admin policy is created by default, corresponding with the admin role. Also in this particular domain, I created policies called blacklist and white lists blacklist is denying post to admin on Web, API, slash, secret and whitelist.

A

Is granting get and post to action to front-end role on way via Web API, slash back-end resource by writing assertions with certain syntax. We can configure fine-grained authorization.

A

By registering these entities, we can do an authorization in two different flows. The first way to do this is centralized access control.

A

First, the administrator of the domain will register a policy granting sports.com fig manager's access to set max seat memory settings. Then the service that was bootstrap with its Athens certificate will make a request to configuration service manager by asking to set maximum error setting to 8 gigabytes when the other service. In this example, configuration service manager receives the request from the client first, it will verify their client subscribe with its pre installed, Athens GA circuit.

A

After the verification, it will extract the service name from the surf kit and make a request against Athens to ask if the sports off config managers does have access to set max heap memory, setting value and decides from the response.

A

So this is the centralized access control model. Another way to do otter, ization, is to use this centralized model in this model. First, the administrator of the domain will register a policy granting sports.com pick managers access to projects at secret. It's exactly the same flow as we used in centralized model in this model before the service making a request to the secret management system.

A

It talks to Athens server, to get authorization role, token or role certificate, which attests that the service is in the particular role, I think after getting a row token or role circuit, the service will make a request to the assistant to receive a retrieve a project act secret by submitting the credential which go from Athens server before the secret management system receives the request from the client of synchronously and periodically receives policy data from Athens server.

A

When it receives the request, it will first verify the Prudential. If the Prudential is role circuit, it will verify with its pre-installed Athens CA circuit. After verifying the Prudential. The system will extract the role for an role name from the credential and compare with the roles that were written in the policy.

A

If the role name matches and the policy is explicitly granting their action on the particular resource, then it will be, it will grant access itself.

A

By using this flow, all information will be on the host, so the system doesn't have to contact and outgoing service and can make the decision then and there. In conclusion, the two major features of Athens our service authentication authorization for a service authentication Athens, provides identity. X.509 search gets to each instance on your cloud. Without human intervention for authorization, Athens can provide precise and frequently configurable access control with single source of truth.

A

Today we use Athens in Yahoo Japan to authenticate and authorize each services access on our multi cloud environments, we've been using OpenStack now using pivotal application service and starting to use kubernetes we being able to frequently and precisely configure our authorization policy in our standardized access control model by using Athens. If we look at each cloud environment, there are also many other ways to do this. For example, in kubernetes we can use East EO to authenticate or authorize each service, so we also considered integrating Athens with a steel.

A

When you hear this for the first time, the question can be. Why is deal or what is a steel? Some of you may not be too familiar with steel. Steel is an open-source product that connects secures controls and observed services. It does automatic load, balancing and fine grained control of traffic. Behavior provides pluggable policy layer and configurable. A API enables automatic metrics, logs and chases for all traffic and provides secure with service to service communication.

A

This teo has many attractive features. It has now surpassed version 1.0 and its production, ready and already in CNCs landscape and the philosophy of service matched strongly supports, serve microservices architecture since Athens strongly supports fine-grained access control in multi cloud. By integrating these two products, we can get the best of both worlds.

A

Before talking about integration, I'd like to review some basics of sto mixer in sto service mash, when an app in a pod tries to access to other service or pod, it will contact through employ proxy, which can be automatically injected to each pod. This employ proxy will afford the request to other proxy and receiver side of proxy will get the configuration of traffic management and access control from mixer mixer stores, the authorization policies for access control.

A

Before talking about integration, I'd like to review UPS by considering a way to integrate Athens with Sto, our prototype design is to use mixer. Adapter mixture has an interface to add your own adaptor to support customized authorization. The adapter can talk to our back-end servers with preferred protocols to achieve attributes for customized authorization. By using this interface, we've created a prototype design by adding add Athens's mixer adapter.

A

This is how the authorization with the adapter works in this prototype. We use row token as credentials. An app makes a request to will first get a roll token from Athens, with its bootstrap certificate, then submit it with its request. The rotor King will be sent through and boy proxy and the proxy on the receiver side receives it. It will then pass the row token to mixer to request now an authorization Athens adapter on mixture will fetch policy data from Athens server, periodically and stores on memory.

A

When mixer receives a request from employed proxy, it will verify the wrote him. First then extracts the row name and compare the roles that were written in the policy to check. If the request is granted or not. This is exactly the same flow as the centralized access control model.

A

This is just a prototype. We have other simpler ways employ application. Pod gets provisioned with Athens service, identity, x5 and nine circuits using an Athens identity. Sidecar these Athens x.509 certificates are then leveraged from mutual TLS authentication by sto employ proxy during service to service calls. We still use mutual TLS authentication by default, which we also needed a way to define authorization through the Athens data model.

A

We created a controller to convert Athens role or policy mappings into service role and service role, binding, steal customer resources in order to go through this architecture consider an example, front-end and back-end service. We want a way to authorize only the front-end to be able to talk to the back-end service using the HTTP GET method in Athens. The role and policy names will represent the back-end service and the policy will contain the get HTTP method as an action in the assertion any authorized service.

A

In this case, the front-end will be added as a member to the backend role. This steel controller will fetch the role and policy information from Athens and convert it to a steel service role and service or binding or customer resources object.

A

Once these customer resources are created, a steel pilot will pick them up and convert them into an invoice. Auerbach configuration once the front-end service calls. The backend and boy will check the spiffy URI of the incoming certificates request and will check if the principal it has defined in memory is authorized to access that action.

A

Now I'd like to show a demo for the first prototype, I showed.

A

So I configured domain on my Athens Oh.

A

It's not showing.

A

Sorry too, mister.

A

A

So first this is the domain I configured on the domain name is Athens and we have an admin role and front-end role and there's a Athens dot instance service in the member, and we have policies, admin policy by default and I added blacklist policy and white lace policy and there's a service called Athens instance. This service is bootstrap the idea with the search gets by a hello, Athens.

A

So I'm going to use these client search, kids that was bootstrap by Athens and corresponding private key to make a request to Athens server and also using see a search, get Athens is see a certificate and getting a row token and I'll convert the row. Token I'll encode a token to big 64 and pass it to the script I created to generate a command to run a mixer client command.

A

So in this command, I've configured typing in a mixie check command by targeting mixer host as sto telemetry service and destination services, NGH, service and service is making a post request against two resources, for example, and one example to web EIP is slash back end and the another example to the web. Api is last secret and I think I only added the policy to allow the access to back-end and I didn't add any policy granting access to secret.

A

So this access to the secret should be denied and also I'm, not putting the road talking on the header and Athens that's role. Oh, this is the default header name, but it can be configured and the other part is printing the command. So I'll just run this by passing the road token here. Will you get two examples of commands? One is to be expected to be allowed and another one expected to be denied so just type this in the one part I already attached in.

A

Then this one is check the RPC completed successfully and the check status was okay. So let's try the another example.

A

So the another example is accessing two-way VIP, where the API slash secret, so our PCH check is completed successfully, but the check status was permission denied and the request was rejected. So this is pretty much for the demo. So let's go back to the presentation.

A

Okay, so um for future plans, Athens already support providing at Amazon machine image and to support Athens on kubernetes more easily we're working on docker images, first servers and also help charts, we're also working on production, izing components to support stills original mutual TLS authentication.

A

These features will productionize Athens, x.509 circuit project, provisioning and authorization flow using a steal and boy I'd like to share some of the resources for Athens as well. We have a website github repo slack channel and google group, and if you have any further questions after this session, please contact me via this email address. Please join us. Thank you and I'd like to thank Alan steam and for infra team at oath.

A

From here, I'd like to open the floor for some questions, I'd like to ask our evolution from oath to join me to answer questions.

A

Thank You Prabhu.

A

We can use.

A

This any questions.

B

So it ins provides you see and the provider so with a steel you can plug in the our back policy so that, with the custom resources with a steel, 1.0 custom resources you can plug in this controller, which will convert the attends, are back policies directly into sto. Are back to that answer. A pressure.

B

Any other questions.

A

Yes, so if you have any questions after this session, please contact me via email address. Thank you very much.