Continuous Delivery Foundation cdCon 2020, 20 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Policy-driven Deployments in Spinnaker - Beth Fuller, Armory

Description

Policy-driven Deployments in Spinnaker - Beth Fuller, Armory

A

Hi, everyone welcome to cdcon 2020., hopefully, you've been enjoying the talks that you've already been to and the rest of your day ends up being it's delightful. I hope I can bring you something interesting. I will for sure be taking a slightly different approach than the other folks, I'm here to talk to you about policy driven deployment.

A

My name is beth fuller. I am a senior product manager at armory. Today we're going to talk a little bit about people policy and I'm going to sprinkle in some pop culture.

A

As part of our agenda, we're gonna really focus on personas and how those personas interact with those three pillars that we're gonna talk about: to create a stained glass window, I'm taking really a product manager, old school, unconventional product manager, approach to talking about the problem of how do we deliver software across the sdlc in a secure, safe manner?

A

There's a lot of different ways. This happens to be one that I would recommend.

A

So what drives you when I think about the ops folks as one of the personas that uh would benefit from this? I think about the devops team or the ops team at puppet, and they were delightful. We had some of the best conversations and they really they. Let me um become embedded in the team and become part of the team which was really important to me as a product manager where I was building products for ops people.

A

As part of that, I got the opportunity to learn some of the things that drive them. One of those things is they actually don't mind, sometimes when there's a couple of emergencies, because it makes things a little bit different, it breaks things up. I found this to be interesting, but that's why the whole this is fine. Everything is fine.

A

They love that challenge. The other thing that they love. Is they love meeting their slas and slos? Do they really? No, they do the thing that drives ops. People is actually keeping that infrastructure up and running, making sure that people have the ability to do their jobs. They have this really important job. Their job is to make sure that everybody else gets to do their job and they need to do it via monitoring tools.

A

They need to make sure that they have provisioning management tools and they need to make sure that the deployment infrastructure is good to go for the developers.

A

So the other thing that impacts ops, people, which I found to be completely fascinating- is that one process one process and it has a tendency to break on a regular cadence. Everybody knows about it, but they also know that they don't know what will happen if they try to fix it.

A

So they just adjust their pager duty rotation around how the frequency of this particular process when it breaks so only one person, hopefully in a year or six months or whatever the cadence is actually has to wake up at three o'clock in the morning and do whatever the thing is.

A

The other thing that impacts them would be new release, new code and old code. So, from a new release perspective, they need to make sure that whatever is released into the wild does not impact the slas and slos for the customers, and that becomes very important. So how do you make sure that all those things are taken into consideration?

A

We'll talk a little bit about that and then there's old code. I think we've all experienced that tech debt, that old, fragile code where you're like how do we gently move our infrastructure away from this into something that's a little bit safer, hops people. This is a thing that they have to think about on a pretty regular basis, and it is a thing that keeps them up at night.

A

App devs or devs, whichever new phrase we want to use for these fine folks, what drives them artisanal coffee. The other thing is delivering software, so they are develo developing and delivering.

A

Based on the infrastructure of those ops team, new software new features, they are making sure that our world is a better place by delivering new feature functionality and that's amazing.

A

The other thing that they care about are cves. No, they don't. um I mean they care about them and that they have to usually fix them, and that makes them sad.

A

The other thing that they really love and really drives their everyday is making sure that their product manager is super happy yeah, um but I care about making sure that we all get to work together and that I'm understanding the challenges that they have, that our ops people have and then next we're gonna talk about cves and then security people um and how all of that ties together with the sdlc process, so keep walking with me. It's going to be fun.

A

I promise so grab your girl gang and let's talk about the importance of open source vulnerability management process. I know it sounds exciting, not nearly as exciting as harley quinn and all her and all the birds of prey, but it is exciting nonetheless, so having a security posture for your open source project actually helps with adoption.

A

This is great because, with adoption you have additional community members and those community members are going to come from organizations where there might be a security team that has an interest in making sure that the code that is in place in that particular environment is free of vulnerabilities.

A

In fact, there might be full teams sets of teams whole teams, dozens of teams within that organization that care about all the software that gets included into that ecosystem. So if you have an open source project, one of the things that you might take into consideration doing or adding, including is a vulnerability management process.

A

So this is going to help you with your security posture. It's going to help with adoption and it's going to help security. People feel a little more warm and fuzzy about the products that are being included. They have a lot going on in their brain and things that they have to manage.

A

Let's talk about that security, secops and ctec astronomy for those of you who haven't seen sneakers. I am going to use this couple minutes to strongly encourage that you watch it. It's a rad movie. um So there's no point me talking about c-tech astronomy, except for the fact that that was a plug for sneakers. um I think it's streaming on something um when I think about the sec ops for security folks, I think of this scene in deadpool 2., I'm a big deadpool fan.

A

So I'm going to try to limit the deadpool references here, but there's a scene where cable and deadpool are fighting in the prison. Hopefully you've seen it. It's been out for a few years, probably not a spoiler alert and at one point deadpool and his ryan reynolds way says you're. So dark, are you sure you're not from the dc universe? And all I could think of is like oh security people.

A

They are kind of they're super witty they're, smart, they're sarcastic. They have to think about things in all sorts of different ways. Sometimes they can be a little bit dark. Are they marvel? Are they dc, maybe they're a crossover who's to say so? What really motivates security folks, a lot of things?

A

One of them is that automation makes their life hard yep. I said it. Automation is not necessarily a win for security people. Why?

A

Well it's not a win, because automation means that you can deliver that much more, that much quicker, which means they have smaller and smaller and smaller windows to verify that what you're delivering is okay, because they don't want their name in the news that makes them sad. It makes a lot of us sad because it's usually in the news for a bad reason.

A

Instead, what they really want to do is they want to make sure that things are people are educated that things are working the way they should um they don't want to have to worry about every single deployment that happens. uh What they want to worry about is why are the api keys in github? Why did why? Are they there? Github actions is causing some people to do some different things that perhaps they have already learned not to, but those guard rails aren't quite in place. So security people really want to focus on that.

A

How they can make sure that all those secrets, too many secrets, are not leaked out into the wild. The other thing is they want to make sure that you are not using the same password that it is not on a sticky note or if it is on a sticky note.

A

At least it doesn't make reference to it's a password and what specifically it is, I don't know I'm sure, there's a rule there, um because I think I use post-it notes so, but don't it's bad um and they want to make sure that your password isn't like your child's name and birth date, because that's pretty easy to figure out. um So they want to be able to educate people on what are great ways to do. It use a passphrase use like your favorite place to travel the year that you went there and something else. No.

A

You could probably hack that I don't know, I'm sure they have a system. I'm not in security. The other thing they want to do is make sure that you don't click on that link. You don't know what it is sure. It looks like it's an amazing coffee shop that just opened up near you, and that sounds amazing, because you care about all the new rotisseries coffee rotisseries, but you don't want to click on that link.

A

So are you collaborating with your people?

A

We just talked about how all those different people have an impact on each other, but we didn't talk about how they work with each other and the answer: is they typically don't so one of the things with policy driven deployment is how to get people to start collaborating more with each other and with their technology, and so we're going to talk about those three pillars. Now that we mentioned keep with me, I'm sure it's going to make sense at the end.

A

So, let's talk about provisioning management to start with and when I think about provisioning management, I think about that first persona that we talked about, I think about the ops team and what they want to do is they want to automate and templatize the infrastructure they want to use terraform to to provision kubernetes cool, that's what they want to do and they want to make sure you want to make sure that as they're creating their infrastructure for their dev test and prod environment that you have the appropriate guard rails in place.

A

So you want that protection right, because you want to make sure that if you have bob the intern that he can't release code to production, only alice the principal developer can can deploy code to production so having those policies as code or those policies built into the infrastructure, helps build that connective tissue and it helps make those security folks feel just a little bit more like they can take a step back, not quite yet but they're thinking about it, they're considering it.

A

It also allows your app devs to spin up their own environment and they don't even have to worry about the different rules.

A

I know everyone talks about how wonderful it is at netflix because they get to do this now, you're, never going to be a netflix, so stop trying to be a netflix unless you are trying to compete with netflix and be a netflix, you are what you are so play to your strengths, and so part of that is having the ops team, who gets to build that infrastructure so that your dev team or your app devs get to spin everything up and it makes it easier for them and all those guard rails are in place.

A

So maybe you can start to move the needle so that the ops team doesn't need to do everything and the devs have a little more autonomy.

A

Then you have your pipelines as code pipelines is code cd go on all right. So now you have your continuous integration, your continuous delivery, and that is amazing and it scares the crap out of security people.

A

So you've got to think about what are the things that we can do to build, that connective tissue, that collaboration between the teams, so that we can make everybody's lives a little bit easier.

A

So one of the things that you can do is with your pipelines as code. Is you can start to build out some of those backs pack best practices? You can start to build out that templatized way of delivering um of building out your pipeline. So you have your version control. You have your code review changes, so you might have um within your pipeline. You have a process where bob who's an intern. Maybe he can deploy to production, but before it goes to production, somebody else has to review it.

A

So alice has to review it and approve it and make sure that everything's okay before it goes to production. So that's all part of your pipeline as code process, but part of that requires that you have those policies as code to ensure that that bob and alice relationship is copacetic.

A

So let's talk a little a bit about policies as code, so policies is code. I really view as um it puts the bow or the frame around your entire sdlc process. So what it does is it helps to create the relevant rules for governance and compliance.

A

It helps to build that in. So, if you need to care about gdpr, you can care about gdpr. If you need to care about pci dss, you can care about that. uh Whatever your best practices are for least privilege. You can do that if you have other best practices, you can do that if you need to do something so that your internal auditor sees things or you have qa and qa needs to approve it or you have security scans and everything needs to be scanned before it goes to production.

A

Your policies as code using something like opa will help to build all of that in and then you have like this amazing process right. All of those things builds your sdlc platform, that's great, but I just talked to you about a whole bunch of single panes of glass. Didn't I yep, I did so one of the things with the concept of a single pane of glass. That I'll be honest with you, I don't like it. I don't like it, because it's not actually how things work today.

A

In reality, there is no such thing as a single pane of glass. I mean there is, but what a single pane of glass is supposed to be? It's just not essentially what you have is you have organizations where I talked about all those really cool groups.

A

You have your ops people, you have your your devs, slash, app app devs, you have your secops, um your security folks and, depending on what time of the life cycle within your organization, they joined, they're, probably all using different tools, in fact, they're, probably using like a dozen different tools and with that there's a lot of context. Switching they just have disparate tools, different languages in order to accomplish simple tasks like provisioning code. That sdlc process is a whole lot of single panes of glass.

A

So instead, I like to think about it as you're, taking those single panes of glass and you're, taking your own unique set of single panes and you're, creating your stained glass window with your pipelines or your policies as code as the frame around that.

A

Hopefully that makes sense. I can't see your faces, because this is a recording. So for making the stained glass window, you have the ability to define your infrastructure as code.

A

You can, and in doing that, um you are starting to create um your willy wonka golden ticket golden provisioning set, uh it's golden provisioning infrastructure, and then you have your pipelines as code where you get to specify your pipeline definition and you get to do that once in source code repos and then it's a template that you can share across all the teams and that's magic again. That's your willy wonka ticket and then you have your security and compliance where you get a codify security.

A

Best practices and policies, which is your pipelines, is code and then all of those things can string together and that helps to build out collaboration.

A

So you have your provisioning, which is allowing you to create the appropriate guard rails for your devops team, your pipelines, which is your peace of mind, knowing that the people who should have access are the only ones who do have access, and then you have your secops and they have the ability to take some steps back to help speed up delivery.

A

So did we really talk about policy driven deployment? Well, we did. But what we talked about is the process of how you get to policy driven deployment.

A

I didn't talk about the specific tech so for your provisioning, maybe you're using terraform group of bash scripts, you're using puppet and, let's say you're, using ansible um for your pipelines as code, maybe you're using argo cd, you're using tecton you're, using spinnaker and you're using jenkins and then for your security and compliance you're using opa, there's, probably something else out there, but I know opa. So that's what you're, probably using and all of those things whatever that combination is. Is your stained glass window, those policies?

A

This code are connecting all those bits so that the policy is the bit that is driving. What those guard rails and that protection is for your provisioning and for your pipelines as code, so that you can ensure only the right. People are delivering code so that you can ensure that your infrastructure is exactly the way. It should be that it has all those policies already in place.

A

And then you have all those policies as code that are just helping to frame everything and keep all that connective tissue going, and so maybe you're moving people a little less cable and a little more deadpool.

A

When it comes to how they're feeling on the security side and then, while maybe the ops people, they know that things still might burn. But they know that their name, their company's name, is less likely to be in the news. And then you have your devops.

A

They still have to build the features that their product manager said, but as part of that, they know that it is quicker and easier for them to iterate and to get to that done, done state and to deliver those features for the customers, like a lot of you out there, so that everyone is happy.

A

So with that any questions.