DevSecOps Best Practices for Identity & Access Management

Transcript

Losio: In this session, we are going to talk about DevSecOps best practice for identity and access management.

Let's try and define in a couple of sentences what we mean by DevSecOps best practices for IAM. Without some strategy, DevOps team can basically ship great products, but product basically enable hackers to steal data quite quickly, and enjoy that, and do quite some damage. In this session, we basically try to cover the nitty-gritty of integrated security through DevOps, discussing what the major concerns are, and how we can address them.

My name is Renato Losio. I'm an InfoQ editor. I work as a cloud architect. We are joined here by four industry experts on DevSecOps. I would like to give each one of you an opportunity to introduce yourself, and just give a couple of words on how you basically started, and where you are in your journey to the whole DevSecOps.

Murthy: My name is Nivedita Murthy. I am an Associate Principal Consultant at Synopsys based out of Boston. I've been in this industry for more than 12 years now. My journey to DevSecOps started when I started hearing about it through my clients who were asking for it while I was helping them mature their AppSec program. I love tinkering. I love cutting down any manual effort. It worked pretty well, just to get into this field and learn more about it.

Sottl: My name is Marek Sottl. I'm a DevSecOps architect or engineer in SolarWinds. After SUNBURST attack, it's very interesting. I've been in the industry for 10 years. I run my own open source library, which is called the Ultimate DevSecOps library that you can find on GitHub, which is collective resources about DevSecOps. I also run a YouTube channel, which is called Hackitect's playground focusing directly on DevSecOps practices and how to automate cybersecurity in our DevOps world, and how to make application security better.

Parecki: I'm Aaron Parecki from Okta. I'm a Senior Security Architect at Okta. My main role is doing education and trainings on OAuth security. I also actually participate in the IETF, which is where the OAuth spec is made. I'm contributing to those specs and actually helping build that stuff from the ground up. It's a lot of fun. I'm all in in the world of security, and OAuth, and all those things.

Rajan: My name is Ashish Rajan. I'm based out of Melbourne, Australia. I work as a CISO in my day job, on the other side of the fence, as Renato was saying. My introduction to DevSecOps was about five, six years ago. I started the largest DevSecOps Meetup group between Australia and New Zealand, and have been part of the community since then. When I'm not working as a CISO over the weekends, I'm a podcaster doing live stream. Still talking about cloud security and DevSecOps over there as well. If you are someone who's interested in cloud security, do check out Cloud Security Podcast.

Getting Started on Best Practices for DevSecOps

Losio: I'm a developer, this is, let's say, Java or whatever. I'm coming to this roundtable, and I know the basics of security, but I haven't really focused on security in the cloud. I want to think about best practices for identity access management, or in general, best practices for DevSecOps. Where should I start?

Rajan: I think the easiest way to start was probably by understanding what you have, visibility of what you have. It's easy for us to start by say shift left. I'm going to do a quote sign over here, just because I think I feel it's been said so many times that I always roll my eyes when I hear people say shift left, because I'm like, what exactly does it really mean? For me, I think the first place that I recommend people start is by knowing what you have, whether it's a CI/CD pipeline. What kind of CI/CD pipeline do you have? If you have possible integrations that are possible for your security tooling that you have. The other one is from an auditing capability, but from a usability perspective, who can access what? This being an identity conversation, I think that ties in really well into some of the identity components of DevSecOps as well.

Sottl: That's actually everything what Ashish shared, it's exactly what I will say too. I would like to add some things because I want to focus on IAM itself. You really need to first understand IAM. What you want to do with that. What is your goal? If you want to have SSO for developers, or if you want to have full blown IAM management for all the users and all your employees, that's very important to focus what you really want to achieve with that. Then I recommend everyone, because I was working with GCP, and AWS, as a partner, I see that people are having the lack of knowledge of the best practices. Go to white papers from Google, from Azure, from AWS, from Okta, from the vendors, and read through that. Check the well architected framework and IAM best practices, which will give you a pretty good viewpoint on what is the identity provider. What is identity broker? How you can work with them. How you can integrate them together. It can give you a pretty good start. Because I feel when you're working with a company, which is trying to implement new identity and access management for DevOps, or for agile, and they are trying to implement some new automation around that, they basically miss the basics. It's really hard to start and start rolling. It is really good to go to some Identity and Access Control white papers and read them first.

The Benefits of Shifting Left In Terms Of IAM

Losio: Mentioning SSO is a very good point in that sense. I was thinking now, when we say shifting left, what are the main benefits in terms of IAM to help this shift to the developer? If there is really a shift to the developer.

Parecki: I'm a big fan of making things easy for people and putting too much responsibility on individual developers for keeping track of their own keys is not really a good idea, because nobody likes that plan, and nobody should have that risk. That is one of the benefits of centralizing it in an IAM solution is that, then you can't really mess up as an individual developer, because your access is being managed by the centralized place. That does just simplify things for everybody. I'm a big fan of those kinds of move the access control into something where the security team can manage it properly, and audit it. If that is also able to let you into the servers that you're managing, that's also fantastic. There are some pretty cool tools available for that as well.

Getting Management's Buy-In for Single Sign-On

Losio: I was thinking if there's any benefit there in the sense of like, I'm thinking about starting a company, starting a project, whatever. You might start and not think about that. As a developer, I may think about a new idea or a new startup, whatever I'm working on, probably a single sign-on is not the first thing that comes to my mind. At a certain point, I will feel the pain of not having it. That's at least the way I see it.

Parecki: I totally agree.

Losio: What is the experience in the sense of, how do I then push that concept to the management, because it's not something I can implement myself? I don't know if someone else has any advice in the sense, if you feel like it's something that the developer should push or should just come from up?

Murthy: Like you said, implementing an SSL solution or an IAM solution, is a pretty big deal. I would say just go small parts. When you're talking about DevSecOps, it's a whole lot of processes, there's a whole lot of stuff going on. Take a breath, and start with something small. Start with something you know you want as part of your process. I come from the AppSec side, so I'd say, ok, let's do a simple thing, let's do a SAST scan out there. Or if it's just about providing access to the SAST tools, I am a big fan of groups, wherein the security team gives access to the report for that, and the team can access the report whenever they want and look into the results. At the same time, you're giving the freedom to the team itself to add or remove or manage that group. In terms of access management, I prefer doing group rather than individual, because like you said, going by individual access, it's a big pain. Ultimately, it does not work in the long run. You do not keep sight of who's leaving, who's joining, who has moved to another team, and all of that. An IAM solution definitely helps with that. At the same time, start with something small, and then keep on adding as a part of a sprint process so that you're confident that you are actually doing things, and it's working out. As soon as something breaks, you know where exactly it's breaking, and you know where to fix it over there.

Sottl: You need to start small. As I was working also with some small startups, it's really good to create small groups or define the roles which will reflect what your people are doing. Then the roles like embed them in your groups, and then the users and roles in IAM for AWS. It's really good for this very common case, it's like, you have three to four roles to start with, to separate the duties between the developers and application admins or security. What I forget to mention, and this is a point that's a little bit out of IAM, but it's about the best practices, you need to think about the organizational structure that you have. Especially in a cloud environment, where like almost the companies are failing when they start something, they just start small. They grow it organically on what they build, and they forget about something that they need to create dedicated accounts for IAM, for example, where they can manage their users, or a dedicated account for logging. This will help them in the future do really good least privilege and separation of the duties. They can easily manage that with any IAM solution. This is what I just want to add. That's something to think about from the beginning. You can start small. You can have three accounts for dedicated purposes, few groups. Then you can iterate to a much better approach. For example, GitOps, that's my favorite part. One of the best things that I ever saw was like developers, they have no access. They do not need to have access. They just push their code to Git, and then with a CDK or any automation, a semi-permanent role is created, which will deploy the solution, and after it is deployed, it disappears. That's one of the best approaches that you can have. It takes time to iterate to that point.

Implementations that Simplify and Streamline IAM

Losio: We're going back now to the topic of the best practices for both IAM also, but in general as well. We already mentioned a couple. I think you mentioned separating accounts whenever you work with cloud providers. Even when you start to think a bit bigger thing which can separate. Before, we mentioned groups. I was wondering if anyone else has any other best practice advice or things that a user can implement that doesn't take too long but will help in that process?

Rajan: Yes, from a cloud perspective, I think what everyone over here has already covered in terms of organizational structure, as well as looking at identity. Something I'll call out, especially considering we are talking about DevSecOps as well. Consider using the cloud managed services as well. I think the reason being, yes, you can have an open source option as well, but sometimes you find if you're building in a cloud environment, your service is provided by the cloud, provides you a lot of integration across the board. I normally find that to be an easier conversation, especially in the beginning. Once you go beyond a certain scale, you definitely can't work in that 100%. At least for the initial stages, if you're trying to look for something, what people said over here, figure out the organization. How do you want to segregate logically as well as network wise as well? At the same time, figure out the identity. Single sign-on is great. As well as the third one being is to understand whether you can use the existing services from your cloud provider instead of using something which is probably not designed for cloud, that's probably my recommendation.

Parecki: As a startup, you often just start hodgepodging together. I've definitely been there myself, and seeing how things can turn into a mess. I like the idea of letting the smaller teams in a large organization manage themselves, and that idea of group managed access makes a lot of sense. I still believe that individual at level control is probably safer on the security side. The flip side is if you have to go through a process that goes up the whole chain and back down in order to get one person added into a role, it's not efficient. I would like to see more delegation of the ability to add people to those groups, so that the smaller teams can manage the access themselves.

Managed Cloud Services and Vendor Lock-In

Losio: There's one topic here that just came up that I find quite interesting was the topic of managed services, cloud provider. Of course, when we think about IAM for AWS, there are some similarities across cloud providers. Of course, they're not all the same. One approach is to go, I'm using that specific vendor, and I'm managing all my security and all my access control and even the Single Sign-On on AWS, I may do it at organization at that level. I stick to the provider. I use whatever the provider can give me with certain benefits, maybe simplicity, or maybe easy to add. On the other side there is a bit of vendor lock-in as well, if I want to think about in terms of learning for the team of best practices in general, best approach. I don't know if you can share some experiences or some tools or some feedback on that. Would you go a bit more on your stick as well on the single sign-on or whatever approach you use, or you say, you're running on Google Cloud, stick to what Google Cloud offers.

Parecki: This is why I'm a big fan of open standards. Because when you're using the standard like OpenID Connect, where all of the products on all of the ends of it speak that protocol, then you can avoid some of that lock-in. Because if all of the products that you're doing SSO into speak OpenID Connect, and all the identity providers that you're using speak it, then it's possible to swap out. I'm not saying it's easy, because there's still a lot of things that are configured in each of the providers, but it's at least possible without code changes. It's more just config changes, which is a lot easier to manage. I think that does help let people know that there is an escape hatch, if they really need it.

Sottl: That's a really good start. It was something that I wanted to say too. When you have Cognito, or any other AWS service, they support OpenID Connect, or OAuth too out of the box. You don't need to think about how we will implement that, you just say this is my identity provider, and I will use it. I was working with the companies using some multi-cloud solutions, for example, Azure AD as a provider of identities, and the Single Sign-On on AWS side. They use one cloud provider for identities itself, and second for authorization and getting access by mapping the groups from AD or managed AD to the groups of AWS. You can do the same thing with Google identity. I saw the same thing with Google identity, as provider of the identity. Then on the side of AWS, you're signed in with a specific group, which is mapped to the group of Google identity provider. You can use different mix and combinations depending on where your company is. If you are like no Microsoft Company, you go with Google, usually, when you are a Microsoft shop you have managed AD from Azure. Or you're on-prem, you can still use it if you have really good identity and access management tool like Cognito or AWS SSO, you are independent. There is some pain on creating the groups, assigning the people to the right groups, and then mapping the groups from your identity provider to your identity broker or solution where you're assigning.

Rajan: Having started my career in identity access management, we spoke about best practices earlier as well, the whole cloud agnostic, cloud vendor lock-in conversation becomes a lot more easier when you know what your source of truth is. If an organization doesn't have a single source of truth for identity, you may be working in Google Cloud, AWS, name the cloud, the standards are open. I may decide as a business unit that I want to have my own set of identity and another business unit may decide they want to have their own set of identity. Everyone's using open standard, but they're like, two Ashish, two Aaron, two Nivedita, but then five Marek, then a fifth Renato, and you're like, maybe the one thing that people can take away from this conversation could be the fact that make sure you at least have one source of truth for your identity across the entire organization. Then on top of it, you can build the identity practices for SAML, SSO, OpenID, wherever you want to take it, but just make sure at least you have your identity sorted as one source of truth.

Thinking about Identity Management in the Long term

Losio: That's very good advice. The problem I have with that, I always thought that I should do that, and I never really managed to do that. The reason is, let's think about a scenario where you use Google or you use whatever provider, Microsoft, or whatever company, and you have the account, and then you start to use AWS for your cloud project. You don't start all at the same time, you start with a couple of developer that plays around with it, or IT that provisioned the very first few instances a year ago or whatever. You start with one, two accounts. The two accounts was not really a good idea, good enough to say, ok, we need probably because it was not that easy as well at the time, to use a single source of truth. It was like, ok, I can just create those two accounts. Then the 2 accounts become 20 accounts, then they become 50. Then suddenly you have those two sources of truth. It's pretty hard to go back. Usually, it's not that you start intentionally with going through that. It's just a pain point that you build up with time. Then you want to say, I move to a cloud provider, or I do something and I start with identity management. Unfortunately, identity management is something that developers tend to feel like a pain point more than really something you want to work on. I was wondering if you have any advice to start the way around. Like I move into the cloud, and I'm not saying just use the root account or just create one admin and forget, but it's like, what should be my next step to think a bit more about identity management? I don't know if anyone has really solved that problem.

Parecki: I agree, it's a tough problem because, yes, it does start like that. It starts small and just turns into a monster later. It seems like the kind of thing that you should just be more proactive about being intentional about. When it is possible to tie an account into a SSO flow, definitely do that at the beginning of the project, because yes, it is really hard to migrate or not possible to migrate these later sometimes.

Rajan: I probably even add something over there with the standard as well, to make it as agnostic as possible, difficult challenges that snowballs later on. As long as you stick to open standards, whether it's SAML, OpenID, having that as a backing, then not create your own standard just because you feel you're special. If you had the source of truth narrowed down, that probably would be a great one.

IAM in the Future

Losio: Back a few years, I was not thinking that much about IAM. I barely knew it existed, and I thought it was just a service on Amazon at the beginning or whatever. I was wondering, now we talk a lot about it, because we probably feel the pain, but are we still going to talk about those things in 5, 10 years? Where do you see the world going in that sense? What's the direction you see?

Murthy: I think we still will be talking about it. We are considering now passwordless access. We're talking about different ways of accessing, multi-factor authentication. We've still not reached out there, especially with security tools, we're not exactly up to date with the latest access factors out here. I think 10 years from now, we will be talking but in a different sense, instead of just being at the beginning stage of who's going to get access, how do you manage access? We'll be talking further about how do we track it? How do we create analytics from it, or something like that?

To that earlier question where it was one source of truth. It is required. I've seen that case with one of my clients where that was our main challenge, because we didn't have records in one place. We had access records coming in from three, four different places, actually. We couldn't figure out, how do we set up this whole system? How do we set up the SAST tools, or security tools out there and make it available to teams without actually bringing the whole process? Yes, seamless access, but at the same time applying the rule of segregation of duty is always going to be there even in the future. We would be talking, maybe not to the level of it being so complicated, so daunting in terms of implementing it. We started earlier with DevSecOps, now everyone knows at least what is DevSecOps, we're talking about what other things can be included as part of it. There will be more mature conversations out there, for sure.

Losio: We haven't talked until now about the topic of passwordless, as well as ways of authentication that might really change.

Preventing Secrets from Leaking, In Terms Of IAM Strategy

Any tools on preventing secrets from leaking in terms of IAM strategy.

Sottl: It's related to each other, what we're saying here. A few years ago we called it SDLC, software development lifecycle. Now we call it DevSecOps. I think that in a few years, it will have another name. Preventing secrets from leaking, you can see already today, what is happening, like AWS, or Google Cloud is providing the IAM access analyzer which will help you at the early stages to get an understanding of your access, to get an understanding of what your users are actually doing and how to group them. I think that this trend will evolve. It will help you to get some organic overview on the IAM access to give people the permissions that they really need, and not people who need the services itself too, and they are using. If they will not use them, you will start to remove the permissions that they don't need. The algorithm like Zelkova, and others that are appearing in AWS world, they are helping to do that. They are doing the semantic based evaluation of IAM to give you an understanding of what your people are doing, what they really need to enforce the least privilege access. I think that will be the next evolution.

I will not say machine learning because I don't want to use this word. It will basically evaluate the real world usage, and then reflect it in your IAM policies and it will change. Regarding the secrets leakage, you need to scan your Git repositories all the time. It should be part of the pipeline. It's the first step that I'm doing in my CI/CD, basically run Gitleaks, or any other tool which is very similar, to scan your repository on the credentials of any type. In the same way you should have already existing IAM permissions in AWS. There is a really great tool which is open source, it's called Cloudsplaining, that can explain your IAM policies from the data exposure and privilege escalation, and it can tell you that you can escalate your privileges not by a human but by some service IAM. Really great stuff that you can do for your IAM.

Losio: There's a growing number of third party open source tools that's amazing to explain your IAM on AWS. I think the same amount of providers is a sign as well that it's not that easy to understand what that IAM rule does at the end of the day, because the number of services keeps growing. What you have there, what used to be a simple JSON file with two, three people in your organization is something else at the moment, so, much harder to understand. I don't know if anyone has any advice as well to help prevent secrets leaking apart from not using secrets. That's the other approach.

Murthy: Try and move away from not using secrets, rather, a better way of approving access. A lot of people have been talking about just getting rid of passwords in the first place. You wouldn't be able to leak something which is not there in the first place. It's more based on geolocation, based on which IP you're coming from, or where the request is coming from and how the request is coming. You actually identify that user and then provide access. That is another case. Till we reach that level, then we have that level of data coming in and a better understanding of how we can actually authenticate or authorize such people.

Password vaults are something that we recommend out here. If you have that, use that, enforce it. Your SAST tools, find it. There's Gitleaks, there are several secrets scanning tools that you can easily apply and include it as part of your DevSecOps implementation, as part of post-commit hooks or something that they just scan for it, and try and avoid. We are humans. We can't remember all of our passwords. First, I simply use a password manager for all websites. I don't keep a track of it. As a similar way, encourage your developers, encourage better ways of storing passwords or better ways of handling them, rather than just letting it be included as part of your source code, or just keep it in a secure manner.

Passwords and Secrets Best Practices

Parecki: Along the lines of passwords and secrets and things like that, I am really excited to see a lot of progress being made on the hardware security side. As in, using the built in, we have now in our phones, a hardware security module that's linked to touch ID, face ID, and that's now being put into computers as well. That's all part of being able to use that private key in a way that it can't even be extracted. If you can't take it out, then it can't be hacked. If your process involves somebody logging in, and then getting a string of characters of the secret and putting it somewhere else, that's a pretty big gap in your security, because that string can leak. If you tie everything down with hardware security modules, then that concept doesn't even exist, there is no way to copy and paste things. I'm excited to see that working its way into more of the ecosystem now.

Losio: You're basically saying that that's the direction we are taking is less and less password, less stuff that is going to be leaked. We'll still have maybe in 10 years now, whatever, we still discuss the topic, but would be a much more clear way to handle our security approach.

Parecki: I hope so, yes.

Rajan: I feel that you can't really go passwordless without the standards themselves updating, like even if you take the OpenID, the next change that happens you get a token. If someone's using client credential, there's long term client credential that people are potentially using for a long time. We're encouraging standards that require us to keep a secret. The logic is flawed from the perspective that, if our standards depend on having secrets kept safely, we probably will not be able to get there sooner. At least from my perspective, maybe it's a bit of a left of field advice, but I accept the fact that people are going to use secrets for some time to come. My dad still uses a secret, which I still have to remind him. I'm pretty sure we'll have a lot of people who would be slower in technology that we would have to remind people their passwords and probably we are their password managers. I think one thing that I always find works is at least having the capability to rotate secrets and use temporary secrets. I think Mark was mentioning AWS, and most of the cloud providers these days have a temporary credential that you can use, so you don't need to have long term credentials. Even if your secrets are leaked, the time of window of opportunity for anyone to misuse it is quite low.

Parecki: That's exactly the thing I was trying to get out there. It's pretty widespread now to use touch ID, face ID on your computer and phone, which is good from the user's perspective. We are now seeing that work its way into the server to server world as well, where servers can have hardware security modules. We can stop putting in credentials, copying and pasting secrets and expecting developers to keep those safe. We can now use the hardware security and private keys on servers and avoid the need for a server's password in the client credentials flow in OAuth and OpenID Connect.

Rajan: Because API enabled vault, kind of like what you mentioned earlier, hardware modules, and most developers love API driven conversations as well, they can totally go now for an API enabled vault where you don't really have to know what the password is. You make an API call that just brings in the password, you don't even see at the end of the day what it is. I only know a handful that can do it at this point in time. I don't know how realistic that is.

The Adoption Curve of DevSecOps Best Practice

Losio: If I look at this chart, now, what you asked before is like, do you have a single source of truth? It's almost only saying one or one-ish. I'm probably the only one saying I have two, and I feel bad. That's life. When we look at the reality, where do you think we are in terms of the adoption curve in terms of DevSecOps best practice, also in terms of IAM? Do you think we are early adopters? Nivedita, if you have any, where do you think we are?

Murthy: We are at an early majority. A lot of people are talking about it, a lot of people have implemented it in some form. I wouldn't say a full-fledged implementation. We are not at that stage where no one knew about it, or very few people knew about it and have started implementing it. We do see a lot of companies at least implement DevOps. DevSecOps, I would say at least 50% of that population has already implemented in some form or the other. It's rapidly progressing compared to it being a slow pace over there.

Parecki: That sounds totally reasonable to me.

Sottl: Maybe I have one thing that I want to mention that we didn't talk about, but it's related to the current state of implementations. I think that we already are behind the early adopters, lots of companies know how the KMS works, how the secret managers work. We didn't talk about secrets rotation, that's also one of the things that companies are already aware of, and they understand how to do that, even in the serverless world. There are secrets that are not only from temporary credentials, but if you have some secrets that you are storing in DynamoDB, or S3 buckets, or whatever, you have an option to rotate them in some periodic times. You can authenticate against this service and then withdraw the token or the secret, and in 10 minutes it's going to be different. This rotation of the secrets is also becoming a de facto standard. I think that this is no big pain for the companies to implement that today.

I think what the next step is, is really understanding your IAM, if you have thousands of users to do some fine tuning, to do really good grouping of the people who belong to each other, who should be in some specific group of IAM. I think that's the next stage of understanding all the calls or the API calls or the needs of the developers, what they actually need to access. Because what I see in our company, and also in some engagements, I see that people are discovering all the time new permissions that they really need. Lots of permissions are going away, so it's like evolving, again, the fine tuning for years what is the access that they actually need for their job.

Rajan: I want to put another spin to the whole adoption curve as well. I feel like DevSecOps goes back to between enterprise versus a product based company is quite different as well. Probably from an enterprise perspective, it's still early adopter because a lot of pockets of business units do DevSecOps, but if you look at the broader landscape of the entire company, do they even know there's a security champions program or DevSecOps going on? You come across people still like, yes, we do that. This guy Bob in the team does it. I could be biased as well, because it's a very small pool of information, but I feel early adopters is definitely enterprise. To Nivedita's point, the majority adopters are more product based companies, just because they had to deal with the ongoing challenge of having more frequent releases to production that has forced them down that path where, we needed to be able to do testing quicker, have unit tests more automated. They are more in the majority category for me personally, at least the way I've seen it.

DevSecOps Learning Resources

Losio: I was wondering if anyone has any advice, really, in terms of really pure education. I'm a developer, I've been maybe experiencing a bit of security on the cloud and managing a few things because I had to, but I want to learn more. I'm not saying necessarily in a structured way. I don't need necessarily a certification or whatever. Where should I start? Aaron, if you have any other suggestion in terms of documents?

Parecki: Specifically on the single sign-on and OAuth side, I have a handful of videos that I've put out on the Okta developer channel, and some other conference talks I've done. I've done one recently, actually, that I think does a good job of describing the problem space, and how single sign-on provides a lot of solutions without even getting into the technical bits of how it works.

Murthy: If you want to learn about cloud security, and this is something that I did actually, for free, you can just go to AWS and they offer a lot of resources to start, what is cloud? How does cloud security work? What are we talking about in terms of config, or how do we secure it? They offer free courses out there, you just have to select the pathway that you want. There is one specific for security. You can start off over there as well. In terms of DevSecOps, if you don't want a course but you just want to start breaking things, that's exactly what we do in DevSecOps, technically. Install Jenkins and start playing around with it, see what it offers, and try and create a test job or something like that. That's where I would start. Just research a little bit, there are several resources out there in an unstructured way where you can learn, this is how it works in this tool, or this is how you actually implement a DevSecOps pipeline, and what does it include out there? That's one way to learn as well.

Secret Manager Control Plane as Write Only, and Data Plane as Read Only

Losio: Unpopular opinion, secret manager control plane should be write only, data plane should be read only. Anyone has any opinion on that. Does anyone agree or disagree?

Rajan: I think the difference between a data plane and a control plane, 100% with you. I don't think it's an unpopular opinion, it's just not an easily accepted opinion. Because the complexity that comes with defining fine-grained control is harder depending on which environment you're in. I don't think it's an unpopular opinion, personally. I just feel like the implementation is the harder piece, where, how do you even get a grasp of the control plane in a large, like 400-application company, getting everyone on board. Basically, it requires almost like a strategic move. Having been part of one of those strategic moves, I can tell you right now, the biggest challenge of implementation was acceptance of the fact that people would not have what they used to have previous access. You just spend months trying to explain to people, you would still be able to do what you're doing, it's just a different kind of control. It goes into a very different rabbit hole. Maybe an unpopular opinion from that perspective. I normally tend to just go with at least the way we've worked in our team in previous companies as well, we tend to go with, application tends to do the granular control and coarser controls for on the top, like from your single sign-on perspective, or any interaction that you want to do. That's all very coarse grain. We don't go into the detail of read-only. We leave that for applications usually.

IAM Action Items

Losio: I'm a developer. I'm a cloud architect, whatever. I joined this roundtable, I loved it. You've convinced me the value of IAM. I have two hours to do something about it tomorrow, what should be my action item?

Sottl: I would like to join what Nivedita said already. It's like, there is AWS Skill Builder, which is being improved. It's pretty easy. Nowadays, everything is on the internet. You can go to YouTube, you can learn a lot. It's for free. You don't need to pay any super expensive education. You can go to Udemy. You can go to Cloud Guru. You can go to Cloud Academy. There is plenty of deep dives. It's not so costly. You can go there and pick the topic that you are interested in and start to learn. You will realize that you spent one month on learning because it will be very interesting, you will start to uncover the areas that you're interested in. That's my recommendation.

Parecki: Totally agree. Lots of excellent free resources now.

Rajan: If you want to check out Cloud Security Podcast as well. There's definitely the angle of AWS, definitely the angle of Azure, definitely the angle of Google Cloud. Why we created it was because you get a biased opinion. You go on YouTube. Netflix has been very open about how they do security, identity access management at scale, they're a very popular example. Quite a few other examples as well. Some of them have been on the podcast, so if you want to check them out, totally fine.

Murthy: I'm more of a doer in terms of learning while breaking things or just practicing things. Just get access to a free instance, which I know there are a lot of those, and start tinkering with, what does this configuration do? If I deselect this option, what happens? If I select this option, what happens? Try and learn through that. That will be the best way is learn by trial and error method. That's how I learn a lot. Reading is great. It's helpful. It's useful to start, and like rather not break at the beginning itself and reinstall everything. Yes, trying and practicing it out with the test incidents and see how things work out. That is my recommendation.

See more presentations with transcripts