IAM Very Confused: A Friendly Guide To Cloud And Modern AuthZ - Tom Cope

Please go. >> There we go. Right. Hello everyone. Welcome. Uh I am very confused by the title of this presentation and my current state. Uh we got 25 minutes to make you uh identity and access management specialists. Um the first who am I? Someone who can operate in correctly. Hello, my name is Tom. I'm currently a principal consultant at plane. More on that in a bit. I also ex so of security. Got by Motorola been kind of fapping around in this field for about 12 years now. Got new CBS to my name. We got bloggers coming up and you can catch at Defcon later this year. Got a few certifications if you're interested. Got an amazing website.

That's just my opinion. Um who is control plane? We are a um cyber security consultancy company. We kind of specialize in cloud and Kubernetes based pending test and uh secure design. We do um what else do we do? Um we do um source code security supply chain a bunch of stuff um all kinds of different verticals for like dev sec ops training modeling. Uh if you're interested come speak at the back. Uh we also are primary contributors to flux if any of you use it. We do like a a short version of that. Um, you know, lots of sort of good things. All right. Identity and access management. I picked this meme very specifically cuz this is how I feel

whenever I talk to someone about I am. Don't worry, I'm more scared than you are. Um, you can also you can tell how long someone's worked in I am by the kind of the middle distance they stare out into whatever you mention and a little twitch every time you mention past management. Uh, what is it? It's three A's. You've got authentication, authorization, and audit, which is who are you? Are you allowed to do that? And please make note of it. Um, this is referred to as OR N. This is referred to as OR Z. Uh, which is very difficult for me because I'm British, so I spell it like this. The Americans spell it with

Zed. I like to use the standard, but also I like to be right. So, it's it's a difficult place for me. Um, we're going to be talking about all Z today. I'm using Z the American and not the Z but you get the point. Uh what is it basically? It's the process of um it's process of determining what resources and actions you are allowed to perform. So you have a human or a machine or a smiley face. Uh it goes into a policy decision point which then takes a bunch of context time access IP address etc. You feed in a policy which will touch into and then this into a policy enforcement point and then you say yes

sorry no you're not allowed to do that yes you are allowed to do that or step up authentication to etc. Um when do we use this? You you use it all in your business. I assume you do. You don't just let anyone come in the doors testing. Um you have like permissions on Google workspace and internal application things and you also have products. So a lot of people these days you know you're building a software of service platform something like that you need to implement some kind of IM into your system. What's very weird is these things cross over a lot in modern businesses. You will end up in some situation where you want to protect some

piece of data and you'll end up writing your own product in your own business to provide some sort of defense. Um, a very good example of this is in one of my one of my old companies, we had a custom application running Kubernetes to control port forwarding to certain bots. And if you wanted to access our Postrest database directly, you went logged into this application and it went through a manual review process to get an approval from people or through open ID and then open the port for you which was a nice way for all these activity. U I'm going to run through all the different kinds of IM and I'm going to talk about some

cool ways to implement it in your business. So first off, attribute based access control. What is this? This is the idea of putting tags or sticky notes on onto things within your business. And these can be kind of your project. Is this is it secret? Is this restricted? And you can apply these things to like um what's cool about them is they can be static or dynamic. So any of your people running a cloud when you send up a new EC2 instance, you can automatically just slap a label on that and say this is controlled by the engineering team or this trained information. And you can do the same like terraform or documents created in a folder. Lots of different

ways to do that. These can be environmental like what hours are people working. Is this a remote connection? These are commonly used to step up authentication. If it's remote, get them to what kind of two layout they're using. You have metadata about authentication themselves. Um this is commonly used as Zur if you have the pleasure of um of using Azur their condition their conditional access is very good for these kind of things you can lock down those login very securely by how you are authenticating and you can also have based on the action they're forming this is commonly used as a risk score are you transferring £10,000 on a Sunday over a remote connection probably not the best

uh I borrowed this slide from Amazon which I think is a very good example example of of kind of showing different teams, people working in those teams, manage resources. This is the primary thing you get out of actually access control very simple policy infrastructure team looks after infrastructure things. uh some policies infrastructure looks after infrastructure things but then you can also do very complex things like the finance team on a remote connection and they provide it to a fa on a known device can access restricted um advantages and disadvantages scales incredibly well for the business can not always frame as you want it the nicest thing about it is you link these with sources of truth so you don't need to

worry about keeping your policies up to date because the sticky labels are on your company directory on your cloud environment. If it doesn't have a label, it doesn't get enforced. SC access control is a terribly overused term horrifically. Basically, you've written some kind of policy some way in code or in or as as code or is code that implements policy. You're doing this as code. Python example here of just an admin can access the admin page on a page. You can implement policy as as code and they can also implement in code which is when you have like some kind of like in this case I've got Amazon policy document and you can see here admin on

S3 and they got an example in a regular policy which we're going to touch on later. Um, easy to audit, easy to review, be incredibly fine grained, tends to get out of control incredibly quickly as your business grows. You bring in a new technology, you need a new policy, and you come on role based access control. We've all used this before. It's old, reliable. We've got like an actor, a role, a set of permissions, baking cake. Um, oh, there it is. Um, you've seen, we've all seen this before. And the example I'm going to use this is CCTV in my house. You have like the user. They have the view only role. The role is

there. They have a set permissions for university access. Very easy to implement. Gets the job done in most cases. Is probably what you already have in your business and already using and might already be happy with it. Fantastic. The disadvantage of this is you end up roll explosion especially if you're using something like um like um active directory. You create a new role you're concentrating them and then some ends up with like 50 of them on your business or 100 of them in order to do the roles and then you run weird situations where like only allows so many groups to be attached inside of curros ticket and all your authentication business. I only talk

about that for um but yeah there's there's some options. I want to very specifically get a side grade into systematics. Uh not only there's always this cut and dry attribute based access control is theory at the end of the day because in order to implement this all these tags you need a policy in order to take all of those tags and make a policy decision. And if those attributes are a collection of roles, you've accidentally implemented ro access control. And I specifically call this out so that in your careers when you're talking to people about access control, at any point in the conversation, you can turn to them and say you are technically correct cuz you always are because you're always

falling on some of these systems and you are always technically correct. But this is something important to like holding in mind when you're designing these things. And who knows what that Pokémon is? >> Oh my god. >> Pop. Anyone else? >> But actually answer the the question here. So all the ones I've spoken about before are kind of the traditional access control systems. I'm going to talk about a new access control system that Google implemented in 201 released in 2019 called Sansar. Google's consistent global organization system. So Google photos, calendar, cloud drive, maps and YouTube all use this system that Google created. It's a proprietary technology but the paper of how it works and how it

come together um has been made open to the world. It's a little bit different. I wanted to go through a few slides on this because it's new. It's interesting. It might work very well in your business. Um the idea is based on graph theory. Um we have a model which is kind of how do the relations in this graph work and we have thing called tupil which is the data that is stored in the database that is the relationships. A primary very good example of this is funny enough Google Drive. Um so you have these types of like a document and a user and a folder a bunch of other things and then you define some

relationships. For example, a user can be an owner on a document. Kind of get the idea. And then you can also have like meta relationships where a viewer or an owner or a viewer of a parent folder can read a document. good old graph theory stuff and you end up with a very pretty graph explaining all of these um all of these um relationships um which is very cool. How does this work in practice? I want to share my presentation with my brother. There he is. You click the send button and a tuple is generated for that action which says my brother George is going to be an editor of this document and then that

tuple gets inserted into the database. This is globally consistent deployed across everything can handle a very large number of requests and then my brother receives said document and Google says hey can George or George George can read this presentation and the database then looks at that model to understand how all these relationships exist. It looks at all the collections of tupil and says yes George has a relationship can read with this document and the access is granted. That's how it works. It has a bunch of really nice properties. It can scale massively with your business. It's incredibly fast. Google internally gets this down something like 10 milliseconds per check which is really quick. And you can do

reverse indices which is really nice when you can take an item in the database like a document and ask the database who has access to this and it can very easily explain that to the disadvantages of this. If you bring it into your business, it's going to be awful because you have to take all of that knowledge you might have in a bunch of other places and then put it into this database and end up with lots of duplication of data. you like run someone out into something and that might be stored in like a different application then you have to replicate it into the database but at the end of the day it is very nice when when when

it say congratulations you're now I am specialist you take my award and like go off into business and say you know everything about IM and now I wanted to cover some implementations some ways you can take this technology and use it in your businesses um none of these sponsors. This is just what's out there currently. Um we have um or z which was made by exubers if inspired by Google zanzibar. They have spice db which is their implementation of dual zanzibar but like made open source they have as a product if you want to dabble with it. This is a nice way to get started. Uh we have open fga which stands for fine grain access control which is the CNCF

project. This is the more open-source version of it. Um, originally initiated originally developed by and these guys in my opinion have the best documentation for getting started with like Zanzibar like technologies. Um, if you just reading their docs is definitely valuable for your time. Again, open source. If you're doing policy based access control, open uh OPA, open policy agent is your bread and butter. It's uh the policies are written in a language by called Rego. You can read data from external sources, bring them into OPA to make policy decision. You are probably already using this in your business somewhere. If you run anything Kubernetes related, Gatekeeper implements its policies through this. If you're creating a new business or a

micro service, I'd highly recommend looking at complaining on void with OPA. This works really really well because your application development teams can develop in the application. The security team can then put on void policy in front with your policies and implement really nice fine grain access controls and gives you a nice way of like meshing between teams and being able to have like scalable consistent testing a bunch of developer support. >> Um, who likes Amazon? I am. We got one fiddling response. Well, they open sourced it uh which I was a bit uh surprised to say and it's called CEDA. Um it is basically Amazon IM as an open- source project. Um you write policies

like you normally do and implement a bunch. Amazon unsurprisingly will sell it to you as a product called Amazon verified permissions. But it's a really nice way if you're building an application and you want to implement a permission system and you're already in the Amazon ecosystem to do so. It's incredibly cheap. It works very very well. Um, a company called permit.io actually took this all together and they created CEDA agent which is a HTTP implementation of the CEDA uh authorization language that you can then integrate into a bunch of your projects which you don't want to be tied to Amazon. They also created Opal which is a layer that sits on top of this. so

that when you make changes to your policies, they can dynamically uh push out to all of your little agents whenever you make a policy change. And what's nice about this is it also works with OPA. So if you're in a situation where you have like hundreds of microservices all using OPA as your authorization engine, you can put this together and manage the dynamic policy configuration changes. Um we have Oo which I've been here um it's an interesting product and um I don't have enough time to explain to you but they have a very nice data model for doing relationship based access control like Zanzibar but with better ways of of ingesting the data without having to put

everything like Zanzibar based database is very interesting I would give a look they are coming out with an onre version soon it's interesting And last but not least, uh, Cberus, which is another authorization, is fully open source. They support robot access control and actually use access control. They have a nice little cloud offering that like connect all of your authorization logs into single points. Another good one if you're like deploying in Kubernetes and have like thousands of policy engines. Um, it's also just kind of a cool little project. Um, the main thing I really, really want to stress with anything access control related is keep a decision log. Really look at your business, understand it, and write it

all down. Because in 1 year, 2 years, 30 seconds, you're going to have someone asking you, why did we go down this? Why did we make this decision? And the reason is because you're always balancing these things. How easy is it to use? How easy is it to maintain? Do you get the expressiveness out of the policy range for your business? How compatible is it for everything and how much you're paying for it? Both in the upfront cost of like money, but also how long does it take people to train this? If you ever try to explain someone rego in an hour, please come and talk to me. How I need to learn that. Um, but these

things were important to consider and perfect is the end of good. know that your authorization engine is going to be reviewed for the rest of your business until you can place it. Like it's really important you understand you get it right. You write down you understand why you made that decision. That's it. Thank you very much. 18 minutes. That was a lot of curriculum. Uh the slides are there website add questions and thank you.

genuinely have any progression. Yeah, the um the auction has been pushed back and genuinely impressions as >> yeah what involves is that the the graph datab so the thing that makes the decision doesn't have to be central yes so so Google specifically is built on top of Google technology that's way they like the system database uh and I believe the same open and the other products like allow for recognization there's still one thing I think is execution is policy they're both the same thing yeah whereas the all the other ones I spoke about the policies then like loaded into they have distributed execution Yeah. >> Yeah. >> I work with a lot of smaller companies

and it feels sometimes they railroad based on the text. Anybody move forward? I feel I feel like in a lot of those cases you need to understand at a technical level how they are making authorization decisions and what frameworks they are using and then from a review of that there's a lot of like OPA and all these other products have really nice SDKs that you can easily integrate into existing applications and then trying to push them down that road into migration a new thing that you implement uses that policy decision point and you tie it into an existing language or the other route is forget about everything they've implemented an access policy in front like

with um with and do it all there and then possibly move something that's that's a little bit nicer. >> Anyone? >> Yeah. Um, have you looked at CE? Yes, I had the pleasure of writing that recently. Um, I I like cell. I think it's quite difficult to write and more difficult people to reuse. I think it's a very good fast execution language for evaluating policies. I think is a little bit difficult. It's not as approachable as I think it should be. >> Uh, yeah. Uh, they're both they're both not great. Um but yeah also doesn't implement forms and technically does but again it's confusing

>> so from perspective uh is testing like involved against the web app say uh have you got any suggestions for tooling around that sometimes I feel like the development as employees. >> Yeah. >> The only thing I ever So one of the reasons for using these systems is specifically around centralization of these policies and making these policy checks easier for your particular situation. I always recommend white box testing always because you need to understand how the code making those decisions and then the first thing you do is just Google the end points and don't even use that check. And I think that's really the only approach um for testing black box is really difficult and not really worth the time.

All right. Yeah. Thank you.