Welcome to Mario Star Power, your infrastructure with InSpec. My name is Hannah Matty. I'm a UX designer here at Chef on the compliance team. If you want to tweet me, my Twitter handle is at djpedamapants. And I'm Victoria.

I'm a software engineer here at Chef. More details up there. So let's talk about this InSpec thing. What is InSpec, Victoria? So InSpec is a testing framework that allows you to define your infrastructure requirements, your policy requirements, right? But the TLDR of it is that it allows you to continuously ask questions about the state of your system.

And InSpec, it's completely free and open source. I mean, who doesn't love free stuff? So you can install InSpec in four different ways. We got the Chef client, the Chef DK. You could do a gem, install InSpec. Or you could just download the InSpec package off of our inspect.io websites or our chef.io

slash downloads websites. And there's so many different infrastructure testing tools out there, right? You got ChefSpec. You got server spec. You got test infra. So what's the difference between InSpec and all these awesome test frameworks? Right, so all those frameworks, totally dope.

Here's the thing. They each have their own purpose, right? Chef specs for testing cookbook. Server spec, sorry, test infra is great until Bob comes around and tells you, yo, yo, core test infra does not work on Windows. Server spec, actually, funny story. InSpec was built on a lot of the learnings from server spec. So what InSpec did was take a lot of the great parts

of server spec and just build up on that. That's awesome. So like server spec, InSpec was inspired by RSpec. And what makes it different from RSpec is that InSpec does have all these out-of-the-box resources that you can leverage and start writing your tests right away. What's also really awesome about, I said awesome twice as you hear that,

but what's amazing about InSpec is that in your controls and your profiles, you can write all this metadata in, right? So basically, your friends could understand the code that you've written and you can maintain those relationships. So it increases collaborations overall. And what's even better is that InSpec actually allows you to run over SSH,

WinRM, and Docker transport. It makes it really easy with the InSpec CLI, but this is available across. And whether you have Chef, Ansible, Puppet, InSpec does not require you to install anything on those nodes. So basically, you can run InSpec tests across all of your nodes

without altering the state of your systems, which makes it pretty cool. Right, and that's all done with Train, which is the transport interface that runs in the background to just kind of go ahead and talk to all those systems remotely and locally. Yeah, did you see how excited she was? Yeah, she jumped. Yeah, she jumped. She's like, look how this is awesome.

Completely agentless, hello. Yeah. All right, you ready for a demo? Yeah. Okay, let's do it. All right, should we show them some InSpec shell? Yeah. Let's do it. So the InSpec shell is a pry-based read, read, print, ugh, REPL.

Oh, REPL, pry-based REPL, that allows you to basically run controls and tests without creating an entirely new file. So ultimately, it works sort of like the Chef shell, basically exercising the InSpec DSL, its resources, and its tests without having to write an entirely new file.

So if we come here and we just write InSpec, we're gonna find all of the options available to us, right? So to find out more about how to connect to the InSpec shell, we can just simply do the InSpec help shell. Oh, if I spell that right, InSpec help shell. And that'll tell us how to connect. So I actually spun up a little VM earlier.

So I can just run InSpec shell with my key and my transport as my vagrant machine. And it's already gonna come ahead and tell us what we're doing. So we're running on an Ubuntu Debian 12.04, good to know. Now what do we do? We're in the shell, which means that we're actually connected to that machine. So we can find out what we want about the machine. So from here, if I write help,

I'm gonna find out what I can do in the shell. And it's gonna tell me that there's some resources, there's some matchers, there's some different things I can do here. Now if I go ahead and do the help resources, I'm gonna get a nice list of resources available to me. As you can see, there's quite a few. So here we can pick a really common one, right? So SSHd config, for example.

If you write help SSHd config, it's gonna tell us all about this resource. It's gonna give us an example test, and it's gonna give us a description of what the resource is doing and what it's about, along with a little reference to where we can find some docs on it, which is awesome. Now what the great part is,

let's find out what the SSHd config params, for example, are here on our machine that we're connected to. So if we do SSHd config dot params, we're actually gonna get a nice list of that information. So we already know what's going on on our machine, right? If we wanna find out any one of those specifically, we can just call it out specifically.

So instead of params, let's do port. And we see it's 22. Instead of port, we can do protocol and get a two. Now if you remember, the test that was the example up above was actually saying the same thing, was SSHd config protocol should be two. The cool thing about the inspect shell

is that not only can you query it to find out what's going on in your machine and really dig deep into those resources, but you can also run the actual test inside the inspect shell. So if I copy this and just paste it down here, it's gonna run that test for me and it's gonna show that yeah, the protocol equal two, because we saw that a minute ago. Say what?

And what's even cooler there is that if you ever needed to find out a little bit more about how to write a different test, you could even write help matchers. And if you look at the way the tests are made, I think they're very RSpec like, right? They're the RSpec tests. So you'll have a matcher there and you can, and if you write help matchers, you'll find out all the different kind of matchers that you can use across the resources.

So this test here is a great example of what an inspect test looks like. So inspect has this concept of profiles and controls. So the profile is a directory where the controls live. So within a profiles directory, you're always going to have a controls directory. And those controls directory, that controls directory will have the Ruby file

with your control and the tests. And then you'll have a libraries directory. That's where you'll be storing the Ruby files for your custom resources, which we'll go over in a little bit here. And then you have the inspect YAML file, which the inspect YAML file is the metadata for your profile. So you can see here that I just did an inspect init profile and then I gave it a name.

My first profile, just whatever, while she was talking. And you can see they went ahead and created all those directories that Hannah was just talking about. If we go over here, we'll find it. And we've got some example controls in here. It already provided us with some example controls. So let's go ahead and take that test that we used earlier

and we can say, we've got a test in here now and we can just include it in our controls file, right? However, this is just a describe block. So inspect actually has the concept of a control that allows you to give a lot more metadata information to that test. So instead of just writing above here,

hey, this is so important. It really is though. It really is. But instead of just doing that and hoping people listen to your comments, what you can actually do is you can wrap it in a control so that you'll end up writing something like control SSH one, do and end and wrap it all up.

And then, as you may have seen on main stage earlier, Dominic showed you that you can add some things like a title and a description, right? So you'll have a title here and it'll be title. And you can do the same thing with a description. Now the other cool thing that we can do here is there's a field called the impact.

Now the impact is how you can kind of define how important you want your organization to view that test. So let's say I decide within our organization that we're saying that tests that have like a zero to 0.3 impact are like not too big of a deal. Anything that's like 0.7 to 0.1,

you're like shit's up higher. And so we decide that this test is kind of important. So we're gonna go ahead and give it an impact of 1.0. And now across our organization, everybody knows that this test is important and we should stop when things break. And impact levels are inherited from the ideal

from traditional compliance severity levels. So that's where the concept of impact came in. But you can ideally use them for prioritization as well. But that doesn't actually mean risk for your company. So you added all this super sweet metadata into your control. Now you gotta add metadata to your profile. So if you go back to the InSpec YAML here,

you'll see the profile name. That's gonna be the name for your profile. And then you can give it a super sweet title, your maintainer information, copywriter information, license information, and then a summary. What is this profile for? So you can still maintain your friendships and they won't hate you. And what's also awesome,

oh, you have your version, forgot that part. What's also awesome is that you can add a supports field. So supports will allow you to specify the target operating system for this profile. So if you have Bob who's using Windows, he can't use this profile. So you can prevent him from doing so. And what's great about that is if he tries to run that profile on his Windows machine,

it'll go ahead and tell him, hey, that doesn't work, it's not a supported OS. But it won't fail him out, right? So now that we've got our profile, what would be nice is if we can check it. Cause it's nice to have that little system. So if we run InSpec again, we're gonna see that there's an option called InSpec check. So we can use InSpec check to check that our profile was actually well written

before we go start running it everywhere so that we catch all those things quicker and it takes down our feedback loop there. So if we do an InSpec check on our profile, we're gonna see it all came out cool. However, if I went in there and I was like, well, actually I wanted to add some tags

because there's some other metadata field called refs and tag in here that we can use. But let's say I make a mistake and I'm like tags, bears and monkeys. So basically she spelled tags wrong. It's supposed to be tag. But if I write InSpec check, now it's gonna go ahead and tell me, hey, you actually messed that up. You meant to say tag.

So you should probably fix that. So if I go ahead and fix that, it'll go back to being fine. And that's just a nice way of making sure that everything's right before you start using it. All right, so now that your profile's all good to go, look at that. Valid, true, yay! Now you can actually scan this profile

against your system, right? So InSpec makes it really easy to do so. All you gotta do is do an InSpec exec path to profile and you'll get these fancy little scan results there that tells you what controls and tests have passed, failed and skipped. What's also really awesome, I keep on saying that, awesome, really awesome. I guess it's a thing now. It's true, one of my favorite movies.

That you can do an InSpec exec path to profile, dash dash format JSON to get those scan results out in a JSON format. You can do the same by doing dash dash format JUnit to output a XML format, XML output that you can easily integrate into your Jenkins pipeline.

So that stuff is all pretty nice. And especially that JSON and JUnit output really makes it easy to integrate everything. But we can even do a little bit more with profiles. So there's a lot that we can do with profiles and some of the cool things we're gonna show you now. One of them is attributes.

So attributes are a way of saving secrets inside your profile. So we have an example profile that we already spun up right here. And we've got some tests in here, right? Where we said, hey, princess user is gonna be the attribute user. The default value is gonna be bowser. The princess password is the attribute password. And we're saying we want princess user

to equal princess peach and princess password to equal yo super life. Hello. So when we actually included an attribute YAML file here that has user princess peach and password, Yoshi for life. And if we run this profile, we're gonna see in spec exec, profiles slash attributes.

Then we're gonna go ahead and run that with the attribute file there, with the dash dash attributes in the location of our attribute file. And when we run it, we see princess peach and yo super life because it read our attribute file. So what do you do when that person has a profile,

you have a profile, I have a profile, and you wanna run all those profiles against one of your systems? Well, you're not gonna do an inspect exec three different times because nobody got time for that. So, inspect has this great concept of profile inheritance. Basically, you can inherit the controls from different profiles

and then run them in one inspect exec. So you can go back into the inspect YAML here and you can add a depends field. That depends, you write the name for that profile, the URL for where that profile came from, and in the instance that you are using a profile from our Chef supermarket, since inspect is integrated with the Chef supermarket, you actually don't need to write that URL.

So that's kind of awesome. And then you can go back into your controls file. So when you go into the controls file, you can use include, you specify describe profile name. Oh, there you go. So you can include the controls by specifying the profile name up there.

And then you can say include all the controls but skip those two controls. Or you can say require only these controls from this profile. And basically now, the profile understands its dependencies in terms of what controls that it's dependent on. Right, so this is really nice because it really gives you that control all over the profiles that you're inheriting. So you're not just copying a whole bunch of controls

from one thing to the other. It's all organized and you can find out what you're using really easily. And go back and find out more about it. Here's the other thing that inspect can do for you is we can actually go ahead and vendor that profile and then lock down so that all those dependencies are locked down at that point in time, right? So if we look at inspect again, we're gonna see that there is an inspect vendor

command right here. So if I do an inspect vendor, profiles inheritance, you'll see that it's grabbing some things and it's gonna go ahead and vendor those over to the directory right here. So now we have a vendor directory. Now the other thing that we can do right here is we can actually archive this profile.

We can archive any profile. And what that'll do is it'll put it into a nice little tar ball that makes it easy to share with friends because friends share profiles. So here if we inspect archive, profile simple SSH. Sorry, I've got some go shit.

My computer doesn't get along with it. So we've got a tar GZ right here. Mario meets inspect simple one oh tar GZ that came from our archiving. And now we can go ahead and share that with all of our friends so that they all feel as happy as that. Because you know that's what we do on our free time. We just share profile. It is. It's an important part of the day.

So Hannah, have you heard about the new Docker resource by the way? I heard containers are so in right now. Oh man, I got so excited the other day when I saw that there was a new Docker resource. Because here's the thing, right? We've got a whole bunch of Docker containers running everywhere. I actually took the time to spin up a little Docker container before we started.

And it's called Mario meets inspect. So I can go and find out about it the normal old way, right? Like I can Docker PSA. Here's the thing, I've got a lot of stuff. I can't really find Mario meets inspect. It's somewhere in here. But I have to scroll a little and I'm not totally sure. And I can't find it. And I know it's somewhere in here.

But it's hard. Oh and there it is, right? So what the Docker resource allows you to do is it allows you to access all those same Docker API commands in a simplified way through your controls. So if we come look over here at our Docker love profile, what we're gonna see in our Docker love profile,

that if we describe the Docker containers, its images should include Mario meets inspect. We're also testing some other things here, right? So we're checking the server version, we're checking client version, we're just checking some various things. But just to find out if our container is here, we can run this profile right now.

So if I do inspect exec, profiles slash Docker love, whoops, profiles slash Docker love, we're gonna see that yeah, it did find Mario meets inspect. And that's a nice easy way to find out that my containers are running so I do not have to scroll through a bunch of text.

So that's a really great example of leveraging one of inspect's resources. And inspect, like I said, has a huge array of out of the box resources. But you can create your own custom resource as well. So if we go back to the library's directory that I talked about a little bit earlier, this is where the code for your custom resources go.

And the custom resource is basically a Ruby class that's inherited by the inspect resource. Right, so here we pulled up a little bit of a dummy resource that we wrote for this, right? So you can see at the top that we're just inheriting from the inspect resource and we're just initializing it. And we're saying hey, if anybody asks Mario why so mean,

it's cause of Bowser. Damn it, Bowser. He keeps on throwing them across the world. It's not cool. It's really sad. I know. I always wonder. That would make me really mad. So if we go into our controls, we're actually gonna see that we say describe Mario, why so mean, do it should be Bowser.

And if we go ahead and run this, inspect already knows what to do because it knows to look in that library's folder for a custom resource. So we don't have to do anything special here. We can just run inspect exec profiles slash custom resource and we're gonna see that Mario should be Bowser.

Which doesn't make sense right there when it's written, but you know what I mean. But you get the concept, right? Totally makes sense. Okay, so we've just shown you a whole bunch of stuff on the inspect CLI and the inspect DSL and the amazing inspect shell

which I hope you guys all use because everybody should be using the inspect shell to make sure that they're getting their tests right. And that's a lot of the core inspect. But I'm guessing that most people here don't just have one node that they're running this all across, right? So you can't just inspect exec across everything. That's why we have integrations with other tools.

So some of you may use Test Kitchen. Test Kitchen is used to test your cookbooks across a variety of platforms. You can actually use the verifier portion of your Kitchen YAML to specify the verifier as inspect and then go ahead and run those profiles against all those same platforms. Say you wanna send stuff to automate so you can get those pretty things that you saw on the main stage today

that you really liked. Then you can use the audit cookbook. So the audit cookbook is gonna allow you to define those profiles and then run it as part of your Chef client run. You can even specify an interval in there. So you can have it run regularly with your Chef client run or you can specify your own interval for all those profiles. And then if you really wanna get fancy,

you can even wrap up that inspect profile with Habitat. You should go see the Habitat people for more information on that. Yeah, I heard they have a booth around. And there's a lot of, oh, I'm the clicker beauty. I'm like, sorry. So there's a lot of profiles available, public profiles that you can take a look at

and get started right away. So one of the resources, of course, is GitHub. So look for profiles there. We have some DevSec members here if you wanna raise your hand. They have a great repo there, so some hardening profiles. So I would encourage you guys to check it out. And then we have the Chef supermarket. Again, we have public profiles there.

And then with Automate, our enterprise offering here, we have premium CIS profiles that are included in our offering that you can leverage as well. So that's more into the compliancy stuff. But again, you can use InSpec for compliance, integration tests, smoke tests, whatever you really need to do, security testing.

So there's a lot of different ways to do that. Back to our enterprise offering here. So we're about to release our newest enterprise offering, which includes InSpec and Chef Automate. And it allows you to basically analyze those scan results that you've run with the audit cookbook.

And what's really cool is that you can actually filter down by a profile, a control, a node, or like a platform or environment to really create these curated views. You can do historical analysis as well and see how your compliance status has changed over time. What's also awesome, my goodness,

awesome so much, is that we have a profile storage in Automate as well. So you can upload those profiles to share across with your team, as well as sync those premium profiles right into your name space. So, and we're always looking for feedback on this, so if you guys do have any feedback once you start playing around with InSpec,

I'm happy to hear from you. And what questions can we answer? Oh. Hi, you early on were talking about passwords and whatnot and having plain text passwords and files makes me feel really yucky inside.

And is there any support for using like a Chef vault or even encrypted data bags, HashiCorp vault, something like that to kind of add a layer of, you know, some kind of encryption so that I don't have a text file on my computer with passwords and secret things in it?

Off the top of my head, I can't think of a specific example, but I can possibly find out or we can find out from some more of the inspectors. And Dominic's right there raising his hand to possibly answer. Make Chris walk. Yeah Dom, you could have met him halfway. Yeah, you could have stood up, like gone there.

Sorry. Okay, so yes, you're absolutely right. One of the reasons why we started this attribute system is actually because people were starting to write their credentials into their profiles. And we told them, dude, that's a bad idea because you're uploading that to Git. So if you want your passwords to be there across time,

yes, that's a good idea, but if not, don't do that. So one of the things why we have done the attribute system is to be able to integrate with other sources that provide this information. The YAML integration is really just the first step that proves out the attribute system within InSpec. So the next step is, and we have a couple of things on our short list,

which are mainly vault, which you know, within the Chef universe, of course. And we had something like CyberArk speak up here as well because CyberArk stores credentials, apparently in big organizations, so it's a big thing. These are on our short list of things that we want to integrate with InSpec. I cannot give you any dates yet, any priorities yet,

but this is absolutely on our agenda. And if we look into what InSpec can do right now, which is to go for databases, go for cloud systems, all of that credentials are important. So this will come up, yeah. Okay, first off, thank you for a wonderful presentation with background music as well. And one of the questions I have is,

with the InSpec demos that you've demonstrated, was wondering if there's an idea of having all the InSpec tests on a supermarket so that if other teams want to use those same tests, that way it can save a lot of the development time if it's viable. If you guys are working on it.

In the sense of sharing the profiles across the supermarket? Yes, the InSpec profiles, such as let's say if you have this InSpec file that you've created, yeah. So this is actually really useful here. So if I type in InSpec supermarket profiles,

I'm gonna see all the profiles that are there. So if you have your own private supermarket, you could upload it the same way. And you plans to make it public. Right, and then there's actually for public profiles, yo, I came prepared, I opened this up earlier. I knew you guys, knew people were gonna ask about DevSec. So there's the DevSec profiles that are all open source

that are these ones too, right? So you've got them there and you've got them on supermarket and then you can always upload more and contribute because these are all open source. InSpec is open source, so PRs are always welcome and encouraged. Awesome, wonderful job. I'm curious what a pipeline for InSpec looks like. Is that something that you can do through Chef Automate?

Like for the individual profiles, how you would. Oh, well you could certainly run the profiles. I mean, if you were doing the whole Automate with workflow and everything, you could certainly run the profiles through your workflow, right? But we, as far as running the profiles, like we.

Kind of fun to have somebody running across. I had a question. I noticed that InSpec profiles support versioning. So is there ways to specify which version of the InSpec profile that you want for groups of nodes? Go for it.

It's not that you can't answer it. You can, you're just letting me speak, okay. It's that it's easier if you speak. Yes, there is. So just like, well, first of all, you can specify the versions that you want with your profiles. So just like in the Chef universe, you have got a number of operators

to control your versions. Smaller than equal, larger than, and then of course the, I forgot the name of it. Yeah, the pessimistic operator, exactly. Like greater than this version, but smaller than the next whatever the semantic one is that I'm going to break. So that is fully supported as well.

Also what is really, really important to us with the profiles has been the vendoring and archiving mechanism that they showed to you. Because what we want is that when you have a profile that has a number of dependencies, when you run that and you get a result, we want you to consistently get that result. So that means that as soon as the dependencies are resolved within InSpec,

they get written to a log file. That log file is a snapshot in time. And that snapshot, like wherever you may take it, it will give you the same result. That's why when you InSpec archive in folder profile, as soon as you InSpec archive that, all the dependencies get pulled in, it gets bundled together. And that will always give you the same results.

Now we have had people ask, what if one of my dependencies there are updates, like content auto update? And yes, there is a thing for that. And it should certainly, like we should certainly have a couple of helper mechanisms for that. But what we don't want, especially in the security field to happen is to suddenly change the output of any of these controls

just because one of your many dependencies crashed. So this is the mechanism that frameworks like Golang have. When you work in Go, you know that all the dependencies are fixed and you have that state in time. And whenever you run it, it's going to give you the same results. So it's the same here in InSpec and in Docker and wherever you use it.

Habitat, by the way, too. Habitat's Docker expert, which you have seen today, does the exact same thing. You had mentioned locking the verifier or putting the verifier into your kitchen suites. Are you able to run InSpec side by side

with server spec and bats and all the rest? Or? So if you're gonna specify your verifier as InSpec, it's gonna be switching over to the InSpec verifier. We've got an example down here. But here, hold on.

Here we go. But yeah, that will be running the verifier as InSpec instead of the old server spec that you would run. If an auditor comes in,

once the client's running on 10 different servers randomly, how do you go about running it on 10 servers at once? Well, you could use the kitchen InSpec to test them across your platforms. If you wanna run it on 10 at once,

I mean, you've got the audit, yeah, go for it, Dominic. You can cover it better than I want. Sorry. So there's two ways to run InSpec. One, they have shown you a lot today, which is the remote mode. The other one is through the audit cookbook locally. When you want to execute it only on a number of nodes, I would go in, like, if it has Chef running on it

and it has the audit cookbook running on it, then I would just configure it like a one-off thing. I would pick 10 servers at random, configure the audit cookbook to run at exactly that point and give you back the result. You also have configurations in audit cookbook that may say, only run this every 24 hours, and you just go in there, take that out, let it run, let it come back with the results, then you have your spot checks. The other one is where you have the remote execution,

and the remote execution is primarily designed on InSpec on the open source side to go one to one. So run one InSpec run against one target. But when you have hundreds or thousands of servers, you don't have a lot of fun writing that yourself,

so we have got a kind of orchestration engine for this. The orchestration engine has not yet made it back into Chef Automate, but we are working on this, so that's coming up. It is at the moment still in Chef Compliance, which is the older service which we have, so if you wanna try that out, that actually orchestrates remotely. So TLDR, if you have the audit cookbook,

configure it there, and then run off. If you have the remote execution, then at the moment do it with Chef Compliance, but look out for Chef Automate actually getting that in as well. The other thing I would add is that with the Automate server, you get the compliance reports in the server, so if an auditor comes in and says, I need to know for these 10 servers,

you can go right to the web interface, pull it right up, and do a print screen or send them those actual reports that you've hopefully been collecting the whole time. Sorry, since I've been on the other side of things, so pen testing mainly,

if you have paranoid people like me in there, and you hate them, I get that, they might say, I really don't want to trust whatever you're running on that node because it might be manipulated, and they might just wanna run a remote one against that node, and that's when you use the second mode. Sorry, I just wanted to add that.

All right, any other questions? Are there any more questions? Last call. Nope. All right, can we get a round of applause? And we're... Thank you very much.

Leave this here. We're gonna leave you with this resources slide right here. All the commands that we ran in the live demo portion today are in that Mario Meets Inspect repo, so if you wanna go play around with it, you feel free to.