4 hours 39 minutes
here we are at lesson 6.5 when we're going to take a look at the maturity for the deployment face
so again would be done. Each one of modules. Well, we're looking at from the perspective of the WASP deaf stickups maturity model specific to deployment. And we'll also look at the infrastructure hardening component of that.
So again, we always mentioned just four levels. This there is one for build and deployment there a specific sub dimension for deployment with 10 different activities.
The infrastructure dimension has as a hardening sub dimension with 17 activities
of the sub dimension. Deployment in level one is the basic. They you should have a defined deployment process you should have an inventory for are all of your artifacts. And then as you get a little hired in your maturity, you want to back up before deployment. Your environment depends on configuration parameters,
and you want to have the
make sure you have trusted images that in your repository that you aren't just sitting him on a file system somewhere.
And then again, as you getting a little bit higher when I have a hand over a constant confidential parameters, this is like your database credentials. Any other credentials you want a. A secure method of that against it. Just who knows, email or open text files? Something like that.
And you want to have the ability to do rolling updates which will talk about it, that the Kubernetes section,
which is the idea of putting, are deploying updates without taking the heaven. Any downtime
and you won't have the same artifacts for your your different environments like we've mentioned before.
And then, as you get into the highest level, might you want to have blue green two point employments in your production system so you might have a
Why don't you want to call it preproduction or something? That's production. You deploy their you verify everything's working before you take off line. If you're doing major infrastructure changes and then you move to the rial production and then where it comes online for the for everybody,
she's a question for you. What level of maturity is your organization?
So are you content with this this level of maturity? Or as you were going through these different, much maturing cycles from the maturity model? Do you see some value in going to a different level or new components.
And so what would you change? Uh, do you see? Have you seen 70? Each one of levels. Are you happy with it? Do you see Maybe some portion of it. And these are all it doesn't mean you have to do. Say, there's there's three activities and level for doesn't mean you have to do all there to just this idea of continuously improving your def sec ops pipeline.
And you're not doing def sec ops. What level would you target? So in kind of think through this as we're describing these different levels of maturity and saying like That's where I want to be an organization I may not want to do a fully automated
development containers Micro Services. I think my organization would fit better into virtual. She's whatever it is just kind of. Look at that. Always look at these ideas from the percent perspective of how you would implement this in your organization,
so back to the infrastructure dimension. So for infrastructure hardening,
the bare minimum is you just have a segmented network for your virtual environments. Simple access controls make sure you at least have test and production or your development environment. See, you're not so you can always test this out before you deploy it. And also we have some issues. The end users like What's going on here?
You really want a fully test your applications,
and as you get the higher level, he would want your APS running virtual environments. You want to check the source libraries. Make sure your clusters air hardened, whether you could be using these
thean for stars. Other complaints as a code we talked about before,
you might want to use security in the default for components,
and then rich environments are limited.
Level three. You want to move up to two factor authentication this immutable infrastructure as we talked about? Don't worry, and he distracted by the chaos monkey in the side. But we'll get to it in that level for
and then you also will be looking at role based authentication and authorization on then this idea aversion ING version, the application and version ING version application would follow along with version ing the infrastructure.
And as you get to the highest level, you would be wanting to limit system calls in the virtual environment on then moved towards a micro services architecture, and especially for using infrastructure code. Your production should be near the environment used by the developers. So if you are again using the infrastructure code,
that's that's easy to accomplish because you can always deploy always deploying the same environment
and the use of chaos Monkey, which is a new open source project that Netflix put out there, which is it runs through your environment. You let it run and it just randomly starts taking services off lied, adding delays causing problems, just causing chaos.
Uh, but the Reese,
the reason you would do this is to see how robust your environment is and how you could handle a disaster and to see if some micro service or some portion dies. Is it self healing? Will? If you're running kubernetes, will it? Will it bring it up easy? Would is able to pull the image correctly.
Let's say you have these these delays you're not expecting, does it cost a problem? And then you have this cascading problem down the pipeline.
All of this is there is a really good test of your environment. If you if you can handle it
and the last concept we just want to remember here is we're gonna be doing a verification skin, so it would be the same as the delivery phase. Once you do, you deploy it. We're going to run our whatever, same tool or multiple tools against the what's in the production to make sure it's the same as we saw in the development.
Nothing new was introduced in the application server. Any other issues? We didn't.
We didn't. It's the same application we saw in the same vulnerabilities. If there are any that's left over
the vulnerability scan again, it would be verifying patching compliance configuration, so it might not Onley be a dash tool. But you. This might be a chance for you to run that compliance of the code and verify your in compliance into production. Just like you saw in the development. Nothing was changed. Somewhere between that, you weren't expecting.
There's a quiz. We've talked about this, but I'm assuming you understand. But just just double check that which levelled awas Dev Ops. Deaf psych ops maturity model activities represent the most mature. Implementation is at level 123 or four,
so level four is hopefully kind of understand this is the higher the level, the more mature the activities represent for your organization.
So this ah lesson we talked about maturing the deployment and next we'll take a look at kubernetes.