of light, a cloud of dust, and a ha-he-heil silver, the lone ranger! General Mills, makers of Cheerios, the ready-to-eat oak cereal that gives you go-power, and wheaties, the breakfast of champions, present by special recording, the lone ranger! Rocks are bent by tart and fair, so in the ring you could beware! He's dynamite because he knows! He's got go-power from Cheerios! Yes, he's got go-power! There he goes! He's feeling his Cheerios! Cheerios! Cheerios! Cheerios! The cereal everybody loves! No other cereal looks like Cheerios! It's shaped like little letter-os! No other cereal tastes like Cheerios! It's the only ready-to-eat cereal with this fresh, toasted-out flavor! No other cereal is like Cheerios! You see, Cheerios is made from oats, and every delicious spoonful of Cheerios and milk is real muscle-building food! Each spoonful contains vitamins, minerals, and proteins your body needs! Yes, the good things in a Cheerios breakfast do good things for your body! Help you have healthy nerves, good red blood, strong bones, and muscles! Have Cheerios every morning! Then you'll hear people say... He's feeling his Cheerios! With his faithful Indian companion title, the daring and resourceful Masked Rider of the Plains led the fight for law and order in the early Western United States! Nowhere in the pages of history can one find a greater champion of justice! Return with us now to those thrilling days of yesteryear! From out of the past come the thundering hoofbeats of the Great War of Silver! The lone ranger rides again! Come on, Silver! What's going on? Are you Silver? In the town of Boxville, Sheriff Joe Prindle stood in front of his office, beside a federal marshal, watching three men board a chartered stagecoach. Two of the men were Deputy Marshal, the third known as Moose Varney with handcuffs. Varney and a steep convict had been captured in Sheriff Prindle's territory and held there until the marshal arrived to take him back to prison. We're all set, Marshal! Don't take any chances with that truck. No, sir. Go ahead and the stage. I'll be long, Leader. Right. I'll catch up to you. Let's go, driver! Yeah! Yeah! You gonna stay here in Boxville for a while, Marshal? Only for a few minutes, Sheriff. I'd like a few words with you before I leave. All right. Let's go into my office, hmm? I'm sure glad to get Moose Varney off my hands. Sit down there, Marshal. Varney's mighty tough. Well, he was here in jail. I couldn't relax for a minute. You deserve a lot of credit for catching him. Me? Well, I didn't capture Varney. No, it was what you did. Oh, I slapped the handcuffs on him, but I don't deserve any credit for that. By the time I reached his hideout, he was licked to a fairly well. Well, who did it? The man who found his hideout. The Lone Ranger. The Lone Ranger? Yep. I reckon you've heard of him, hmm? Well, who hasn't? Do you mean to say the Lone Ranger was right here in this county? He's still in this county. I want to see him. Oh, I'm sorry, Marshal, but that's out of the question. Why? He's just recovering from a wound. The Lone Ranger wounded? Yep. He stopped a bullet in the capture of Moose Varney. Oh, was he seriously hurt? Well, he's getting along all right. Yes, he's lost considerable blood, so he's weak. Does he have a good doctor? His ancient pal, Kondo, is taking care of him. Oh, he should have a doctor the best he can do. He's getting along all right, Marshal. Now, he shouldn't have said anything about him being wounded. He wouldn't want it generally known. Well, I'll keep it to myself. Yeah, I wish you would. Just forget that you've heard any mention of the Lone Ranger. Well, do that, but I want to know that he's getting the best he can. He is, he is. I'll tell you, confidentially, he's in my sister's home. Oh.  In town? Oh, in the mask, man. They're both staying there. Well, I'm glad the Lone Ranger's getting good care. Now, Marshal, you said you wanted to speak to me about something? Huh? Oh, yeah. Talking about the Lone Ranger, I clean forgot. I wanted to tell you about the bank robbery. Bank robbery? Where? Grantsville. Two men held up the Grantsville bank and brought daylight and got away with $20,000 in paper money. By the cook's known? There isn't even a description of them. They had their faces covered. Well, if no one knows what they look like, they'll be safe. Not if they try to spend that stolen money. It was from a new shipment of currency, so the bank has a record of the numbers on the stolen bill. Oh. We're distributing printed copies of the list to all the towns in this area. Here's a batch of them for you. Oh, thank you. Uh, huh? I'll see that they're circulated here in Boxville. Well, thanks, Sheriff. Now that's better get going. After the Marshal rode out of town, Sheriff Strindle called at each of Boxville's business establishment and left a copy of the list of stolen bills. That evening, two strangers in town stood in front of a restaurant across the street from the express office and stage station. One was Gopher Ryan, a bank robber and murderer, well known to the law a few hundred miles away. Ryan's partner, a man named Garnet, held a carpet bag containing the money stolen from the nearby town of Grantville. I hear the stage coach. Yeah, it's coming. We'll step across the street at the express office. We better go over there and be ready to board it. Yeah. Wait, just a minute. How much cash you got me in pocket? A couple of dollars, why? That won't take us far on the stage. You broke? Yeah. We'll have to use some of the stolen cash. Well, there's plenty of it in the carpet bag. I'll take out a hundred dollars or so. Turn around so you're back to the street. The people won't see what you're doing. Yeah, all right. You keep your eyes open. Let me know if anyone comes close. Yeah, I'm watching. Oh! Oh! The stage is stopping. All right, Garnet. The stage may not stand there very long. Ryan! Hey, what's the matter? We can't spend any of this cash. What? Look, they're pasting on the window of the restaurant. What is it? A list of the stolen bills. Well, of all the luck. I just happened to see it when I turned my back to the street. That's a good thing. Chances are, we place in town as the same list. And we place in other towns as well. Yeah, and people are suspicious of new paper money. They always look it over very careful. They'll be sure to check the numbers on our bills. We don't care. Spend it. We can't board the stage without cash. Garnet, but what do we do? You figured out, Ryan, you're the smart hombre. It was your idea to abandon the horses. I got it. Look at the man who's unloading packages. What about him? That Pete Chester. Pete Chester? Yeah, I remember him. He was in the Missouri prison when we were... There's always cash in the express office. And that's where Pete is working. A few minutes later, Pete Chester sat at the desk, making out a report. When he heard the back door open and closed. I should have locked that door. I better see who's in the back room. Before Pete could push back his desk chair, two men came from the storeroom. Well, if it isn't Pete Chester. How are you, Pete? I can't seem to place you, Jen. Why, have you forgotten your prison days in Missouri, Pete? Garnet. Remember me, Pete? Go for Ryan. Yes, you were doing a life term for murder. How'd you get out of prison? Busted out. Garnet was in for armed robbery. He was paroled about a year after you left. And the law is looking for you, Ryan. They're looking for both of us. Garnet violated his parole by leaving Missouri. How about you, Pete? I'm square with the law. I finished my term and came here. You're working at Honest Toy, aren't you, Pete? What's wrong with that? Oh, nothing at all. We're glad to see you're working here, Pete. You'll be able to help a couple of old pals. We were never pals. Oh, that's all right, Pete. You'll be able to help us in spite of that. What do you want? Just a little favor. Now listen, get this straight. There's no use trying to black me and me because you can't do it. I have friends here in Boxville and they know all about my past. So does the sheriff and so does the manager of this express office. Take it easy, Pete. We never even thought of blackmail. We just want to borrow some cash. I haven't any cash. Oh, not from you, Pete. We'll borrow what's in that safe. We'll continue our loon ranger adventure in just a moment. Because champions are made not for. Yes, sir. Get on your way. Get on your way. Get on your way with weedies. Champions are made, not born. There's an adage that's ever so true. For instance, slamming Sammy Snead. A golfer as good as they come. Young Sam learned golf the only way. He practiced ours every day. Chippin' him short, drivin' him long. And soon he learned what keeps champs strong. Weedies with milk, you can't go wrong. Today Sam rapes the gallery's cheers. A weedies eater, 17 years. Right. Sammy Snead is a weedies eater from way back. Plenty of nourishment in weedies. There's a whole kernel of wheat in every weedies plate. Okay Sammy, drive that ball. Hey, hey, hey! He's on his way, on his way. He's on his way, on his way. Get on your way with weedies. Because champions are made not for. Yes, sir. Get on your way. Get on your way. Get on your way with weedies. Breakfast of champions. Now to continue. As Pete Chester faced the two men with whom he had been in prison, he knew that they were ready and willing to shoot the kill. He said... You mean this is a stick up? Yeah. Careful got it. Don't let your gun be seen by people on the street, keep it under your coat. The joke's on you. The safe is locked and I can't open it. The office manager's the only one who knows the combination. You think I need the combination? I've opened better safe than that one. I could have opened the safe in the Grantsville bank if it had been necessary. So you two are the ones... Daddy, I'm covering you, Pete. You robbed the bank. Yeah. Oh, that's a good one. What's funny about it? Of the whole country, you came to this area to rob a bank. What about this area? The Lone Ranger's here. What? The Lone Ranger? Yes, he and Tyler are both here. They're the ones who tracked us down to Missouri. I know it. Now track you down again. You can't get away. Oh, we'll get away, Pete. After we get the cash in that safe, we're leaving on the buckboard we saw in the shed. And just to make sure you don't spread the alarm, we'll take you with us. Now take your guns. They got it. Someone's stopping up front. Uh, pull the shade over the window and lock the door. There's two ladies coming towards the door. Now listen, Pete. You get rid of him fast. Don't say anything to make him suspicious. If you try any tricks, I'll shoot you and the Indian. Take guard. He's the Lone Ranger's pal. He's short of range, Tyson. We come for package. The office is closed. A package addressed to Tonto. Ne, take it now. But I have to... Help me wait. Can you go through with other fellas?  Tyson! Yeah, he'll recognize us just as you said he would. Yeah, how about that, Tonto? Remember us? Who, you? Try to be smart and make out your tone. Remember us, huh? Well, that won't help here. Take his gun, got it. And lock the door and draw the window shade. Yeah. I'll keep beating Tonto covered. There, I've got his gun. What do we do with the Indians? We've both got a score to settle with him and the Lone Ranger. Yeah. We'll rope and gag these two and take him with us. Maybe later we'll figure out a way to get the Lone Ranger. As Tonto watched Garnet lock the door and draw the window shade, he realized that now, if ever, was the time to make his move. With lightning speed, he leaped at Lyon. Let's go. Before the outlaw could fire, his gun hand was clamped in Tonto's fingers. I'll help you, Tonto. As he stepped forward, Garnet came from the window with his gun uplifted like a club. Garnet struck again and Tonto dropped to the floor beside Pete Chester. They're fools. Did they think they could get away with a move like that? Why didn't you shoot when the Indian leaped at you? The shot in here would bring half the town. Yeah, that's right. I locked the back door and bring some ropes so we can tie and gag these two while they're unconscious. Right. Then we'll open that safe. At the Newton Ranch House, Randy and Jenny sat in the kitchen where they could hear if a lone ranger called from the adjoining bedroom. Presently, Randy looked at his watch and said, I reckon Tonto will be back soon. He planned to call on the sheriff after he went to the express office. He may talk for quite a while. It doesn't matter. I just... Of course, Cummins. Yeah, that's probably Tonto. I'll open the door and see. Hey, Jenny, Garnet came back with our tunnel. He's raising a rocket, Randy. What are you doing? I don't know. You'd better take him to the courier. Yeah, but I wonder what Tonto is. He's got easy. Come on, son. Scouts continued to whinny, rear, and paw the ground as Randy led him to the corral. The behavior of the paint horse was something new to the rancher. He couldn't understand it. Randy was even more bewildered when he returned to the kitchen and said, When I let Scott to the corral, Silver started cutting up the same way. He pawed on the ground and whinnyed it. They're sure making plenty of noise. Let Scott refuse to go into the corral ahead of time to the rail. I never saw such spirited horses. I don't know how to handle them. Randy. The low range is calling from the bedroom. Oh, yes? Please, come in here. Right. I knew the horses were waiting. Hi there. Randy, what's going on at the corral? Nothing at all. I reckon Silver and Scott are feeling high spirited. Scouts? I thought I heard him. Yeah, he came back from town. Where's Tonto? Tonto wasn't with him. He wasn't. I'll take it easy.  Oh, I'm all right, Justin. A little weak. Have you heard from Tonto? No. I reckon Scott ran away from him. Scott never runs away. Well, he came here dragging the reins, you know. I let him to the corral, but couldn't get him to go inside. He reared and pawed the ground and then Silver started. Silver understood. I'm going to dress. Now, hold on.  Tonto wants you to stay there. Tonto's in trouble. Scott knew it and came to tell me. Now, look. If you get back into bed, I'll ride to town and look for Tonto. I'll even get the share. I may need your help. Well, then I'll help. Will you saddle Silver while I'm dressing? Still. You stand still. Look, if you'd only let me ride for you. I'd be glad to have you ride with me. When Randy entered the corral carrying the saddle, Scout and Silver seemed to know that their whinnies were understood and that action was to be taken. They stood quietly while Randy saddled the big white stallion and his own horse. He was tightening a cinch when the lone ranger approached the corral. The masked man was fully dressed and his guns were tied low. Here he is, Silver. Your horse is ready. Well, thanks, Randy. Hello, Silver, old fella. He's sure glad to see you. Will you untie Scout? Scout. I'm counting on him to lead us to Tonto. Scout, where is Tonto? Take us to him, Scout. Yeah, he's untied. Go on, Scout. Find Tonto. Go on. Look at him go. Come on, Randy, we'll follow him. The lone ranger felt new strength searching for his body as he followed Scout across the moonless plain. Randy's horse was far behind when Silver brought the masked man to the front of the express office. Scout halted there, reared high and whinnied, then dashed between two buildings, past the shed behind the office, and on across flat open country. The masked man stayed close behind the paint horse. Meanwhile, Randy drew rain in front of the sheriff's home and fired into the air. Hold it, hold it, hold it. Sheriff Quindle opened the door. Tonto's in trouble. The lone ranger's riding to help him. The lone ranger? I'm following him. I'll wait for you. You better come. Tonto and Pete Chester lay helplessly tied and gagged on the floor of the buckboard. Gopher Ryan drove the team at top speed.  I wanna put lots of distance between us and the town. We make better time without those two in back. Let's shoot him and throw him out. Oh, got it. Hey, like coming handy, I've got a plan to use them as bait for a craft to get the lone ranger. Get back! Hey, Ryan, there's two horses following us. Yeah? See for yourself. They're gaining fast. Got it. This is a trick of the moonlighter. One of those horses is not a rider. I don't see a rider on the first horse, but there's someone riding the other. Looks quite the moonlight in his way, like the lone ranger's horse. Ryan, I think that is the lone ranger. He's riding past the other horse. Look at him. These horses go as fast as they can. That man's frozen in fast. Shoot him! Did you get him? No. How can anyone shoot from a bounce and wagon? Shoot some more. You gotta get him or you'll get us. We're easy targets on this open wagon. He's still coming. If you can't hit him, fight for the horse. My gun's empty. Fight by. Get out of that. Can't take any aim. I'll start shooting. The lone ranger's throwing a gun. They shoot.  I'll get him. I've still got Kato's gun. Ryan turned to fire, but the oncoming matchman shot first.  He hit the ground, rolled a few yards, then lay motionless. The lone ranger was tired from the ride, but he managed to keep Garnet covered with a gun while he cut the ropes and gags of Tatl and Pete Chester.  You rest. We tank crooks. We'll take over. Gosh, I was never so glad to see anyone in all my life. Ah, horsemen come. That's the share of leading them. Ho-ho-ho. I'll raise you for a surprise. When we're here, we've got the money from the garrison. We've got the money from the garrison. I'll raise you for a surprise. When we're here, we've got the money from the Grantsville bank and the crooks who stole it. The sheriff took charge when he arrived with Randy and two townsmen. The crooks were tied, their wounds dressed, and placed aboard the wagon. Then, Prindle turned to the lone ranger. Well, mister, we're sure indebted to you. No, sheriff. I'm the one who's indebted. I'll always feel indebted to you and Jenny and Randy. Jenny and I are proud to have you in our house. Thanks, Randy, and thanks for everything you've done. I'll help the sheriff take the prisoners to the town. Then I'll see you in town or at the house. We'll be gone by the time you get there. Gone? Yes, we'll stop only long enough to pack our gear and say goodbye to Jenny. How about you? I'm all right now, Randy. He must probably be good as new in two, three days. Strength, come back. We'll meet again. Ah, sure, I hope so. So do I. I just remembered, there's a package in the express office for Tano. Yeah? Or you'll probably get a letter of telegram Pete telling you where to send him. Tano came to the office to get it. That's when he walked into all the trouble. The package isn't for Tano. It holds silver bullets for the lone ranger. Copyrighted feature of the lone ranger incorporated is produced by Prindle Campbell Muir Incorporated. The part of the lone ranger is played by Bracebeamer. Your announcer, Fred Boy. Listen to the lone ranger brought to you by Special Recording.


Keyf소�der, iawn.  You may have noticed for the last three years the Linux community has been embracing Docker fundamentally. People are shouting left right centre about how amazing it is to deploy containers, how it has changed the way that we can deploy applications at scale in a distributed system and we can finally start taking advantage of the Cloud. But like with many things on the Internet, not everyone agrees. Onw, while everyone is shouting about it, everyone is also kind of complaining a little bit. And so you get these really weird kind of like quite flamboyant conversations happening online about, is Docker secure? Is Docker nicely architected? And looking back on my slides, I think the final one doesn't actually relate to Docker, but you kind of like it's kind of similar. And so, I kind of was looking at this and I was like, really? Like Docker has got a huge amount of community support. It's got some very, very smart people work on it. We've already met one of them this morning. Like, how much of this is actually true? And in particular, how much of it around security is true? Like, how secure are containers? And that's what I want to talk about with you today. So my name is Ben Hall, as Rachel kindly introduced. I am the founder of the Othalot Uproar. We build products and we help companies move to containers and help them adopt Docker. Our main product is Cata Coda. It's a free interactive learning environment for software developers. We help people understand how Docker, Kubernetes, all of this cloud-native DevOps technologies are coming along and how you can actually take advantage of them or use an environment driven from your browser. But the side kind of side bit of this is when we started a project, we had a fundamental question. What happens when you give anonymous and restricted access to a Docker container and a Docker server in the browser? And what do people actually do with it? And this is the story of how we try to secure ourselves. And based on the end of the presentation, we'll see how good it is if whether it's still working or not. So if we take a step back and we actually think about what containers are in the first place. So a container in the real world is this huge, big massive metal shipping containers. And they have various key important properties. They're about this wide or about this high and they have doors in a certain location. But most importantly, they have hooks in every single corner that allow them to be connected together and that's how they create this very strong coherent unit which allows them to send billions of items all the way around the world. What's actually on the inside of a container doesn't really matter. It could be MySQL, it could be Ruby code, it could be Python. It could be whatever you want. What's important is that there's these standard ways that containers are built and there's a standard way that these containers are launched and started. Because we've got this standard and because there's a consistent way, we can also now use that to apply a consistent way to start securing them and locking them down in a more effective way than what we had previously. And so if we come back to Catechoda, so the first thing which people see when they log on is a terminal window. This has got a very interesting mindset. People kind of go or 30 developers, not everyone, but 13 developers, kind of have been probably watching Mr Robot the night before and they instantly go like, ah, let's break it. Let's see what I can do because obviously this can't be real, so let's see what happens. And they do a certain process. So the first thing they do is like, ah, which user am I running as? And they'll see that it's root and they're like, ah, even better. So they then start poking around a file system, they'll start exploring, can they get up to the root directory, can they install other packages to extend it and potentially add some additional functionality that they want to take care of. They then at some point kind of get bored and they start wanting to change passwords and then they get really bored and it's like, ah, I just delete everything. And it's kind of like a very interesting mindset. And the reason they do this is because they see their root and then they kind of think, I've got complete control over everything which I can do. And this is kind of true. By default, all Docker containers user which starts them is root. But it's very simple to change the process and change the process that the user is running as. And so in your Docker file, which basically is a list of instructions about how your application is deployed, you can add an instruction in there to say add a new user and then when this process starts, run as that particular user. Or if you're taking an image offline and taking one of the official ones, for example, MySQL, when you launch that container, you can say use an unprivileged, non-privileged, non-root user to launch this process. And so by that, you kind of are restricting what the users can do. They can't install packages. They can't update passwords inside the container. And so you're kind of locking it down and removing some of that privileges. And from our point of view, this helps people get more focused on learning and not trying to break it. But you know, some people still continue to progress and they still continue to explore. And so then they'll start poking around and trying to find out more information about the host operating system. Because Docker is in a virtualisation system which we would be used to in terms of like ESX or then or other hypervisors, Docker doesn't provide that level of virtualisation. Instead, Docker is a kernel virtualisation system. The containers are taking advantage of the host kernel, which is how we get all of the performance benefits and speed improvement because it's sharing the host operating system. But as a by-product of that, the container can see what the kernel is actually reporting. And so you can find out the kernel version numbers. You can find out the uptime of the host because that's reported by the kernel. And then you can kind of like find out free memory, disk space, what processes are happening. It's not malicious. It's just kind of like a little bit annoying. But as with security, like all information is bad potentially, they could use potentially use that as an attack vector. But so far from what we found, it's just kind of like annoying because they would prefer it if they didn't find out. But we'll see. And they eventually find out they can't do much with that and so they go like, huh, we'll just reboot or we'll just do shut down. And it's like, you can't do that. It's a container, like what are you going to do?  There's nothing to shut down. And that's kind of true if you run Docker defaults and the Docker default privilege levels. But if you start changing things and you start updating certain properties, for example, you changed a network in namespace from not being the container, but to being shared with the host operating system. What actually happens is when you call that reboot, it's broadcast a message out on the network bus, the D bus. And that's how you can feel like if you're connected to an SSH session and someone reboots it, you'll get that warning saying it's about to go down. Please save your work and then it just disappears. So that's how it works at the network level. And so when your container is also talking on the same network, it's like someone can reboot the host. And so you need to be aware of these interesting details of Docker. And we need to be very careful when we've implemented CataCoda to make sure that we haven't accidentally elevated the permission of a container. That would be embarrassing. But there's lots of reports about Docker's security and container security and comparing the different container run times and where they fit in terms of security. And as we can see from the middle, Docker has got a lot of green. Green is good. Green is good as we found out from the previous talk. So everything is strung by default. This is what Docker's mindset is. We want strung default security. But there's also some optional ones in there. And that's kind of interesting. So what does optional security mean and what are the side effects of that? And also I think this is probably what will happen if you run processes on a Linux box without Docker containers. It's kind of like having any of this at all. So the first one, which is potentially problematic, is this thing called a fork bomb. This is a beautiful bit of bash scripting if you break it down. So it starts by defining a new function in bash called colon. The body of this function is calling itself and piping the results of itself to itself and then releasing control. So it wins in the background. After it's finished defining itself, it calls itself. And then instantly, you can tell the effects of running this code because you have 4,000% system load, you have 7,000 processes running and that's kind of like the last you'll ever hear from that host until you do a hard reboot. This is problematic and it's basically just a DDoS attack of resource exhaustion trying to use all of the available resources and PID limits and open files and everything like that. This was problematic because there wasn't really good answer on how to protect against this. But in the recent version of Docker and the recent version of the Linux kernel, you've now got PID limits. And so when you start a container, you can specify saying that in normal operating system and normal boundaries, there should only be 10 processes, a maximum of 10 processes running into this container. Let's be honest, if you're running bash, you're probably going to have bash plus a few other processes, but you're never going to need 10,000 of them running in your system. So you set a same default kind of safe limit and then if people do get access to that container and they do try and execute a fork bomb, they'll just get this kind of like going, they can't do it because all of the PID limits are restricted. And this wasn't available before. And if you install Docker and you haven't got it the latest version, you will get this warning. And this is what I really like about the approach that Docker is taking. It's kind of opening up really hard, really deep levels of the kernel and making them accessible to everyone else just by adding a command line property when we start the container and when we start that process. Where previously you would have had to actually understand the internals which no one would have ever done. It would have been very difficult to access and everyone would have just kind of ignored it. And there's lots of other ready settings with Docker and there's lots of other ways that you can secure and protect against your system in case anyone does access that process. And so you can set the memory usage and so you can say that this process should only ever have two gigabytes of memory on the host. And so if there's a memory leak or if someone's trying to launch something potentially malicious, it will limit it and so it can't take over again exhaust all the resources. You can do the same for CPU, you can do the same for the IO disk rights and so you can start delivering a quality of service to your application. And whether just beyond security, you can say that this process will always need this much of memory available, this much of disk IO in order to deliver the performance and the expectations from a user's point of view. And Docker makes that really simple by just again setting a few properties. But once we've actually gone through, a very common and very popular one is privilege escalation. So we've got our container running, we set all the right properties, it's running as a non-root user, but obviously people want to have root access so they can do potentially more interesting things. And so there's some interesting hacks and some interesting exploits floating around. This one in particular was released with an exploit which took advantage of Ambutu 16.04, which was the one which was released a couple of months ago. And it took advantage of BPF, which is kind of like something to do with file descriptors. I mean, it's basically... There was a certain system core which if you hooked in at exactly the right point with exactly the right process, you could have some additional things running as root and then you could core things like setUID and setGUID on a process. You can remap these from being the low, privileged 1,000 user to being zero. If that all works successfully, any additional processes launched would be root and as such you can launch bash and you would be a root user. And you can kind of see things as this happening. So this is the piece of concept which is floating around. You run it, it outputs some nice messages and at the end of it, at the beginning you was Ambutu, which was the non-root, non-sudo user, at the end of it you are root without ever handling the pseudo password, which is kind of quite dangerous and scary because there are no restrictions and once they are root they can do whatever they would like. Again, Docker thought about this and so even though the latest version of Linux kernel which was shipped in Ambutu 16.04 was vulnerable to this attack, Docker have defeated it in there to protect against it and when you start launching a container, you can set a property saying no new privileges and what this is basically saying is given the user which the process is running at when it was started, no matter what happens it cannot request additional privileges, it cannot access additional and it cannot go from being non-root to being root and so even though that kernel exploit exists and that's something which could be exploited if they had access to the container, they still wouldn't be able to get root because Docker is providing an additional level of security. And so this is where it starts getting interesting because you're no longer talking about Docker security, you're talking about Linux kernel security and you're talking about what exploit potentially exists and that as the Unicernel talk this morning was discussing, the Linux kernel is pretty big. There's a lot of really interesting code and a lot of really interesting code which people may or may not have looked at in a while. You only have to look at the open SSL to realise there are certain bugs in there which are quite embarrassing which people have kind of like missed over the years. And so set component of Parma, I'm not going to do that in case I drop it, are two additional ways that you can start locking down processes and start adding additional security in Linux. So when a process is running and when you run a process in Linux, under-covered is doing a huge amount of system calls and this is a trace of just changing the file permissions and with a process in the steps which is actually happening under the covers. And you'll see certain things like if checking that the file exists, it's opening the file and then right at the bottom is doing the actual to mud core to change the file permissions. And so with Docker and with SEPComp we can actually start locking down and start being selective about which system calls the containers can and cannot call. And so this is one of the really key security aspects of Docker because it just fundamentally blocks potentially dangerous, potentially malicious calls from happening. And if you can't call it, you can't attack it and that's itch, you are somewhat more secure. And the way that we can access this from a developer's point, from an implementer's point of view in Docker is through JSON file. There's a default JSON file which you can adapt and you can modify and it's just basically a list of all of the system calls in Linux of which there's around 331-ish and you can just say whether you want them to be allowed or whether you want them to be restricted. By default, you can restrict it and then when if someone tried to do that system call they'll get an operation not permitted and that's itch, the call will fail and so you can add that additional level of security. This is really interesting when you start and look in at how people are exploiting certain parts of applications. This is another exploit against the Linux kernel. What this was doing was attacking certain performance counters in the Linux and was taking advantage of certain different hooks and certain ways that you could call them in a certain order. It's quite complex but the result is it pins a CPU to 100%. If you look and you do a system trace about what's being called, you can see that there's thousands of calls just to these two system calls alone. One of them which ends eventually in 100% CPU and it's locking the CPU. If you run that scale, you could take over the entire box and it would be DDoS and again, you'd have to do a hard rebate. By using system sysc comp, you could take this modify our DT system call which generally most applications never call and there's arguments to say that it should be blocked by default in Docker anyway add it to your set comp profile and even if that application did get hacked and they wanted to exploit via this vulnerability, Docker would say that operation is not permitted and that's such that the exploit wouldn't be able to run and against it securing you even though your underlying system is vulnerable, Docker is adding that additional layer to making sure that it's secure. And this is all great. This sounds great, this sounds perfect but what happens when it all goes fundamentally wrong? So this is what happened to me. So it starts off by enjoying a allegedly nice Saturday afternoon watching some tennis on Wimbledon, watching Wimbledon on the TV and you get this really cool, interesting email from your hosting provider going, there's some malicious or there's some odd activity on your network. You may want to investigate it. It was raised a little bit more strictly than that but that was kind of like the gist. So you go into the control panel and you have a look and you look at the networking and you kind of see that there's 568 megabyte bits per second and it's kind of like, oh my God. Like I know my blog's popular and everything but that's just like, that's unheard of. I don't even know how to generate that much traffic in the first place so at that point you kind of realise something horribly, horribly must have gone wrong. But then you kind of realise like everything I'm running is on containers and so like they couldn't have done that much damage in theory and so there's actually tools within Docker to help you understand what has happened if an intruder just break through. And so the third thing is all of the commands or all of the standard out and standard error is being logged. It's being logged by default onto disk but you can also tell it to log into an out stack or Splunk or other log centralisation systems. And so you can look at the system and it will tell you what happened. In this place, in this case, the attackers kind of exploited the fact that I had forgot to turn off an elastic search instance which had kind of opened up to the public without a user name and password which was pretty embarrassing, but it happens. And so I looked at the log files and you could see what they were actually trying to run and they took advantage of a feature within elastic search which allowed you to make a send Java code which would execute via the API. But obviously, like the elastic search team had thought about this and it was that they had blacklisted certain parts of the Java API so you couldn't do anything malicious. But on the flip side, hackers, there's always two ways to do something and if you only restrict one of them, they'll just find and use the other one which is what they did here. And that's why they're doing things like new input stream, getWinTime, exec. And then they're using that to download additional binaries, execute additional commands onto the server. And to be fair to them, they were very polite, they did try and clean up after themselves and delete the files which they had left over, which was nice, but it was still potentially problematic. Based on the way Docker works, when you start a container, it stops from an image and this is a pre-known pre-built image. And then any changes which get made when that container is running is basically an additional layer on top of that image which is running for that one container. And so what you can do is compare and you can diff between the current live state of the container and what the original image was in the third place. So this is actually really good if you think your system is immutable and nothing ever changes. Like you can actually go in and verify that your application isn't writing additional data or changing configuration files when it shouldn't be because it's all immutable infrastructure. But in terms of security and in terms of figuring out what attackers had done, I could actually see and I could compare and contrast. And you'll see that they had changed certain key properties of Linux. So the net stat, the PS, the SS, this is probably trying to hide the fact that they're doing something malicious. So when you would normally be trying to debug it and you think what process is running, this would have hidden that for you that you couldn't tell. You can see that they've added some SE Linux security properties, probably trying to override something which should have been there in the first place but I didn't implement it. But they've added those in the first place. And then they've added some additional files like DDoS 99 and DDoS 8 which you imagine is where all of the traffic was coming from in the first place. But you can now compare and contrast and you can look at what the hackers did. And because it's running inside a container, I know that if I remove that container and if I delete it, all of the files and all of the potential exploits will be removed with it. I don't have to worry that they dropped a root kit and they're kind of sniffing all of my network packets in the background without me being aware of it because the container, by default, is locking it down in it, offering the security levels which you need. In reality, if I had listened to my own talk, I would have been running the container as read-only mode. A read-only container is basically it allows you to write data to any mapped volumes. So anywhere where you see the explicitly said this container was allowed to write to. In the case of elastic search, that's slash data, which is where it's doing all of the indexes and all of the log files. But everything else it will get due to the read-only file system, you're not allowed to write. So when we think back here, there wouldn't have been allowed to change the bin files because it's read-only and it wouldn't have been allowed to add the additional DDoS binaries because, again, it's read-only. So, yes, they would have got access to elastic search, but that wasn't an empty cluster anyway and that's not what they were looking for. So just by adding this one flag, I would have still been hacked but they wouldn't have been able to launch and do anything malicious on top of it. You can then start combining this. You can say that there's no new privileges so they can't escalate and then you can use AppArma. AppArma is basically a way to define a profile of what a normal running application looks like and you can say that normally elastic search is allowed to write to these directories, it's allowed to access these network options and it's allowed to work in this particular way. But what it's not allowed to do is write to these particular directories and call things like WGet because, honestly, why does WGet even exist inside elastic search container and I still haven't figured that one out? But, again, this is like things which we have to deal with and things which we're having to deploy along with our applications until we get to the point where we can do unicernals. And so AppArma is allowing us to define this normal looking application and anything outside the bounds of that is considered malicious and not allowed to happen. If you actually think of this in a non-database terms and you refer to think about how hackers are trying to raise awareness and raise what they're doing, the amount of defasements happen because the hacker can go in and write to the disk and change what files are there and replace it. If the file system was read-only in the first place, they could attempt to exploit it, they could attempt to try and access all of these WordPress vulnerabilities, but they wouldn't be able to actually write the changes.  So if you think about that, is Docker secure? It's still to be confirmed, but Docker is doing all the right things. Docker has got security by default turned on and they're adding all of the right features in all of the right places to ensure that your systems are as secure as it potentially can be. If you think of the elastic search that would have taken over the complete box and just by running it inside a container means that it doesn't. But Docker is only as secure as your best practises are and if you have got weak security practises, then you are gonna get hacked, i.e. me opening up elastic search to the entire world. And there's also certain things which you need to be careful of. So if Docker has lots of official images on its hub, but it's also got lots of community-driven images on its hub too.  Because once I have access to the Docker file, I can use that to launch additional containers. And these containers could be privileged and they could have all the access which I need and it could have a completely the same access that would if I had complete root access to your entire host. And so you need to be aware that certain things are special. And while it's really useful for containers to have access to this Docker API, if you don't trust it and you don't trust that image which you're running in production, you don't know potentially what's happening inside of it. And so you just need to be aware that that exists. You also need to be aware that when you're opening Docker to the outside world, Docker has got a very unique, very interesting signature when you try and send a HTTP request to the API. By default, it would turn a 404 and then it sets in the interest in headers. So the content type is always no sniff and the content length is always 19. We can use this. There is a beautiful search engine which is going around the internet and aggregating all of the open ports and their responses of every single IP address on the internet and then making it available for you to search. And so you can use this combination of knowing that Docker has this unique signature to find what could potentially be other Docker containers and other Docker demons. Obviously, I've never accessed one of these IP addresses because that would be breaking the Computer Miss Youth Act but you can assume that they may be Docker demons and you'll see things like content type of no sniff, content length of 19, and it returns a 404. If that's a very good bet that this is an open Docker demon, at which point you can do whatever you would like. You can run privilege containers, you can run DDoS attacks at the container and you can do whatever you'd like on the host which is kind of scary. But you can just actually just search for Docker and you can see what people are running and seeing what's actually out there. And most of the time it's with people with registries and if you're actually drilling it, you can use the information and you can use a host header to find out additional bits. So it's an old version of the Docker registry which potentially has got interesting security things which have been fixed in the future versions but they haven't upgraded. Or the running old OpenSSL which has got security bugs and you could use those bugs to exploit it, to gain access and potentially again to get access. And you may be thinking like, no one's actually going to do that. That would be ridiculous. No one's actually looking for these things. Well, for me you should say that. So if you look at the top, the top is from the search engine and it's got certain interesting properties. The main one being that the default response says it's a private Docker registry but that's always already kind of like alarm bowser ringing and the domain is docker.vineapp.com. Again alarm bowser ringing. Vine being the called video clip start-up which Twitter just recently purchased. And so this person went on to the website and it was still up, it was still accessible and they could access it. They could then use the Docker API to sniff around and have a look at what images were available and so they could then go ahead, download the image from the Open publicly available Docker registry and get access to the complete Vine source code because someone had forgot to close the ports. Oops. That's kind of just a little bit embarrassing. So thankfully Docker, this was reported. The registry was taken offline within about five minutes and the person behind it who found this was rewarded $10,000 for reporting it and being the honorable good citizen and actually telling Docker not just taking advantage and hacking it which would have easily been done. There's a great tool and a great website called Docker Bench. Docker Bench basically taken all the things which I talked about today plus 100 other security loopholes and other security advice and it's written it and it's built it as a container. The container will audit check all of your settings, all of your running containers and make sure that they're running in the most accordance to the best practices and it's also a really in-depth long report which is very insightful, very interesting to explain why these settings need to be there in the first place and what potentially happens when it doesn't. And so you should run this on your system just to make sure that you haven't done anything accidentally by mistake. And if Twitter didn't do this beforehand then they would have saved themselves $10,000 and I would have one less demo in my presentation. And kind of we need to remember the fact that by default most of the things which we run at least what I do and Linux systems were running at root without any set comp, without any restrictions and without any security in mind because it's so difficult. It's so difficult to actually understand how all of these moving parts work and by having that layer making it accessible through Docker at least we're starting to get to a secure by default design because without it it kind of just looks a little bit like this. And like if anyone gets in they will just take over the entire box and there will be nothing you can do about it. And like if you think that I don't need Docker I run virtual machines and virtual machines are secure you are somewhat misinformed. This year at the start of the year KVM had an outbound memory access which would allow a virtual machine guest to break out and gain access to the host which is embarrassing. There's not a proof of concept I don't believe but it was a theoretical risk. What there was a proof of concept for was Xenom which happened a couple of years ago and this kind of took advantage of an attack vector in the legacy floppy disk driver. And again like why did my virtual machine hypervider have a floppy disk driver? It's just insane. And then this is what caused Amazon to have to do rolling reboots across the entire EC2 because code running on an EC2 could use this attack vector and break out onto the host EC2 machines which would have been bad for everyone involved. And so you need to do this security in depth. And so with this in mind how secure are containers? So Docker has strong defaults. At the moment there are no known exploits which I can report that Docker has got advantage of and no one is talking about it but obviously everyone is trying and everyone is trying to poke in really interesting ways and it's only a matter of time. So we need to have the strong protections in place and be aware of the potential risks and so we can help mitigate them through things like PID limits and no new privileges and set comp. And we have to remember that really honestly nothing is secure. It's all about calculated risks and calculating how important is what we're doing and how secure does it need to be. Containers are one option, VMs are one option. Can the mining on will potentially make more secure sister but also it may not. You need to calculate this for yourself. From what I'm seeing and what I imagine the attack vectors won't be against Docker. It will just be taking advantage of exploits in a Linux kernel. It will go down deeper and then it will kind of come back up and pop out the other side and have complete access. And so this is why I really like set comp as an approach because you can start locking it down. But as I made a takeaway, to start looking at this of your own system and start figuring out how secure your infrastructure is, running Docker Bench is a great start. It will give you an oversight into what's happening on your system. It will tell you potential risks and it will tell you how to fix them. And it's all for free, it just wins out the container, wins you're finished, you delete the container and there's no harm done. With that, thank you very much. So we now have a 30 minute break but before we do that I'm going to ask Ben a quick question because I think security is becoming a bigger concern for everyone all the time and I don't know if there's any particular security specialist in the room but I feel like we all need to learn a little bit more. So where would you start? Learning security. Yeah, being a better developer, having a bit more knowledge. Cachicoda obviously. Cachicoda will have security training workshops up very soon. Oh, I didn't even do that but in terms of being secure, it's very hard, security is a hard problem but looking at how exploits are happening, how people are being hacked is a great example of what not to do and so that's a very good way of learning by other people's bad practices to start figuring out where there's potential weaknesses and potential risks in what you're developing on a day-to-day basis. That's where I learn most of my stuff is by looking at exploits because then you find other ways of thinking and that's the hard bit. You need to think differently and the best way to do that is by copying other people in many ways. All right, thank you so much. So now we have a 30-minute break. Thank you again, Ben. Round of applause.


So, one of the key concepts in geometry is the notion of a rigid transformation. And we can actually use this to define what geometry actually is. And the idea is, geometry in general is the study of properties that are invariant, that don't change under a predefined set of allowed transformations. So, the idea is that we have something, whatever it is, and this is something that will not change as long as we allow, use a set of allowed transformations of our geometrical objects. Now, the simplest type of geometry, plane geometry, these transformations fall into two primary categories. The first and more important one are the rigid transformations. And a rigid transformation is something that leaves both lengths and angles unchanged. These are also known as isometries. The other type of transformations are known as conformal transformations. And these are transformations that leave angles unchanged, but in the course of a conformal transformation, it's possible that a length might change. Now, if you think about what our definition of geometry is, properties invariant, then our rigid transformations will tell us that geometry, plane geometry, is at the very least going to study lengths and angles, because those are unchanged under our transformations, at least under the rigid transformations. Now, when we include conformal transformations, lengths might change, but then angles won't be. So, angles, very definitely part of plane geometry, because our transformations that were allowed, the rigid transformations, the conformal transformations, those leave angles unchanged. So, angles, very much part of plane geometry. Length's pretty much a solid part of plane geometry. We have to mess around with the conformal transformations a little bit later on, but certainly lengths will also be part of plane geometry. Now, what about those rigid transformations? So, there's a couple of different categories, and the important ones are the following. First off, we have a translation. So, the idea is that in a translation, what we're going to do is, we're going to take every point in a figure, and we're going to move it a specified distance in a specified direction. So, for example, I'm going to take my figure, and I'm going to move it one unit vertically. And so, again, here's my specified distance, one unit, whatever that unit happens to be, one foot, one inch, one mile, whatever, and I'm going to move it a specified distance, and I'm going to move it in a specified direction, in this case vertically. So, let's go ahead and do that. So, I have my figure, I'm going to move every point one unit vertically. I'm going to take the entire figure, I'm going to move it one unit vertically, and I may end up with a transformed figure that looks like that. Another important type of rigid transformation, an isometry, is a rotation. So, in a rotation, every point in a figure is going to be rotated as a specific amount around a specified point. So, for example, rotate the figure shown a quarter turn clockwise around the point shown. So, here's my point, there's my specified point, and my rotation of a specific amount that's a quarter turn clockwise around the point shown. Now, this is probably easiest to do if you imagine turning the paper. Now, since you're watching this on the screen, you can actually turn the screen a quarter turn clockwise, but I can't do that quite as effectively. So, let's see, I'll do that rotation, and maybe I'll end up looking something like this. Okay, so now we know what it looks like, so let's see if we can draw that. So, the idea is I'm going to turn this thing a quarter turn clockwise around this point. That's going to rotate it over to here, and so when I actually draw that, I'm going to end up with a slow rotation too, something about like that. So, that's basic rotation. All right, so next we have a reflection. So, when I have a reflection, what I'm going to do is I'm going to take every figure in a point, and I'm going to reflect it across a specified line. So, for example, I'm going to take this figure, I'm going to reflect it across this line shown. And if you think about this as a mirror, then what I'm going to get is I'm going to get the mirror image of this object. So, when I do that reflection, I end up with an object that looks something like that, and so there's my reflection. Now, there's one last type of transformation that is usually included, which is something called the glide reflection. And so, what we're going to do with the glide reflection, I have two components to it. First of all, I'm going to reflect it around a specific line, and then I'm going to translate it parallel to the line, some specific distance. So, for example, I'm going to reflect the figure across the line, and I'm going to shift it one unit to the right. So, there's my specified line, there's my specified distance. So, I reflect the figure across the line, and I'm going to move that one unit to the right, and there's what I get as the result of my glide reflection.


Hello and welcome to all my DevSecOps Internet friends out there. It is time for yet another episode of DevSecOps is the way. This is episode 10 in remediation month, November is remediation month and today, we're going to talk Ansible security automation. I've got two great guests, two Red Hatters that I'll let introduce themselves here momentarily. First, if I can find my slides here, I wanted to talk about what the series is all about. Here is DevSecOps is the way. We have a monthly security series where we produce a bunch of content, podcasts, these live streaming shows, you see blogs, and each month this year was a different security category. You can see in March we started with vulnerability analysis, talked about compliance in April, all the way through November's remediation, and December concludes this year's series with platform security. If you've missed any of the shows or want to look back on the content, you can find it.  Let's see. This categorization might look familiar to some of you. If not for others, this is part of a framework. This might be a little tough to see, but what we've done at Red Hat is built a DevSecOps framework that helps to categorize security methods, security functions within a DevOps pipeline, and this helps to start discussions around, well, what should I be thinking about if I move over to DevOps in terms of security? Where does security fit? Then we could take our partners, our great ecosystem security partners, and map them along these different integration points to see where they fit and to see where Red Hat fits to provide a starting point for a joint solution. It's been very helpful for a lot of our joint customers. We've got nine categories that you see here, and then there's 34 different security functions underneath these. That's not to say you have to implement every single function at every single integration point. It's more of a guide to say, this is what's out there to help you make a decision. Now, this is streaming on Twitch and Red Hat OpenShift. If you have any questions, feel free to chat us. I see there's already a question. Where are the docs of the DevSecOps framework? I'll shoot a link here out in the chat to show you where to get started. We have a guide, an e-book as well that will guide you along. Please feel free to chat and we'll try to answer those questions along the way I'll be moderating that chat. Let's see. Anything else before I get started? I don't think so. Let me stop sharing here and we can introduce our guests. The one thing I did mention is, yes, we are talking about Ansible. I know this is an OpenShift channel, but if you remember looking at that framework I just showed up, we did have Ansible listed there as a product within the DevSecOps framework. We wanted to bring Emily Bach into the conversation. She's an Ansible product manager. Emily, why don't you introduce yourself to the audience? Absolutely. Thanks, Dave. Yeah. As mentioned, I'm a product manager with Ansible. My main focuses are partner enablement and certified collections, so I'm sure I'll find a way to steer things that way just because that's who I am. But yeah, like you mentioned, Ansible is really a part of everything and has a lot of great synergies with OpenShift, so I'm excited to talk about it a little bit more. Yeah. Thanks for being here and Emily's from Raleigh. She's telling me it's just getting into the perfect weather season with Autumn, with the leaves changing. Yeah. Finally, not well-turning, but it's not late enough to be cold yet, so perfect time of year. By the way, I just noticed something behind you. You've got a little guitar back there. Are you a guitar player? Yeah. I play a few Jack of all trades, Master of None, so I've got guitar, bass, flute, ukulele a bit, so do a little bit of everything. That's awesome. Cool. And then we've got some of our audience members. They mentioned they were from Raleigh as well, so it's good stuff. Oh, my neighbors. Yeah. So we've also got another red-hatter here, my partner in crime with Security ISVs.  Hey, thank you, Dave, and good afternoon, everybody, and thank you for joining us today in our live show. Just like Dave said, I'm his partner in crime. I manage the global alliances in the security segment here at ThreadHad, so I have a few of our close ecosystem partners that we collaborate very closely with to have success at our customers' side. And some of them integrate with Ansible, and they embrace the automation, and they love the security automation story. So here that hopefully we can help Dave and Emily and answer some questions, and maybe post a few questions for them, too. Nice. So what partners do we work with, Ferris? Oh, our tier one strategic partners include CyberArch, Palo Alto, Synopsys, SESDIG, Aqua, and Tegera. And they basically have, like you showed, they work in various aspects of the DevOps and the CI CD pipeline, and they provide a special value to the customer once they deploy their containers in an open shift. And of course, we have the other side, the equation with the automation that they integrate with Ansible, and they provide a lot of value in the automation, especially in the area of secret management and PAM security, like you would see with CyberArch. And we have, like you said, we have a lot of collection of information, a lot of assets, and in fact, we have just finished one solution brief that we did with CyberArch about Ansible and the automation that I would recommend everybody to take a look at it, and we'll include a link to it here. But we also have a full website, actually, dedicated to what we do in with CyberArch and how they're certified in Ansible and so on. Awesome. And you can tell Ferris has got the Southern Charm. He's in one of my favorite places, which is the, you know, central place to make bourbon. So, in Kentucky, right Ferris? I'm in Kentucky, the horse racing and all great drinks. We're actually gonna celebrate thanks, given that next week, and I said to everybody the other day, that's the only place that serves Turkey in a bottle. So that's one of my favorite Turkey in the bottles and somebody said, it's never dry until you finish it. But that's why it doesn't take all day to prepare either. It's absolutely quick. Well, cool. I'm posting a couple of docs here and I'll continue to post some more. Somebody asked where the DevSecOps framework material is that first link is all about the framework and explaining it. It's entitled, How to Deploy a Comprehensive DevSecOps Framework. We also just published an ebook, which has a lot of good information on some of the partners that Ferris mentioned and the work we do with them. Nice. Yeah. So, Emily, let's start with you. You know, this is an OpenShift channel so some folks might not know what Ansible is. Why don't you give us an overview of Ansible? Absolutely, yeah. So if you're not familiar with Ansible at all, it is at its core, no unintended, automation and it specifically enterprise IT automation. So it really acts as a common language between all the tools and apps, everything that makes up your ecosystem as an organization. So to borrow from the Star Wars theme, I'm a big analogy person. So I like to think of it kind of like the Millennium Falcon.   If you're a little less Star Wars inclined, it's kind of like a phone call. You know, originally you would call an actual operator and they would manually connect you to the person you wanted to talk to, which is no longer necessary thanks to automation. It just kind of works in the background and you don't have to face the horrifying prospect of talking to a stranger. So that's really what Ansible is at its core, more geared towards enterprise IT, but it's getting rid of all those little fiddly bits that are better left to computers. Awesome. Hey Emily, speaking of Ansible, so is there a new version coming out? There is indeed very soon. Ansible Automation Platform 2, I believe, is what we're calling it should be coming in early December. So that's got a bunch of great new stuff landing with it. There's a bunch of webinars and stuff going on now and that were in Ansible Fest, but kind of the highlights are going from kind of a more monolithic structure to more of a modular setup, making it more flexible. So we've got automation mesh coming and execution environments, all kinds of fun stuff. But I won't talk too much about it here because there's a bunch of stuff out there. Yeah, I was going to say it's coming up relatively soon in December 2nd, so. Yeah, we're pretty excited about it. Yeah, it's a big deal. Yeah, been a lot of work, but I think it'll be well received. You mentioned Star Wars, so I'm totally distracted. Of course, I've got Grogu here, but I had the best thing I can come up with is some Jalas here in this sticker. Obviously, I'm a Star Wars nerd as well. Love that analogy. So if we think about remediation in this month, how can Ansible help with remediation? Yeah, for sure. So remediation, your system found something that could be a problem or you're trying to address something and you want to fix it. Kind of the main areas that Ansible has been the most useful in for people that we've seen is investigation enrichment. So it can pull together all of your logs from all your different tools in your security operation center. So it's in one central place. It can also help with threat hunting. So it can, sorry. So it helps you detect threats by filtering out noise by putting everything in one spot. You can also set it to really look for specific things in terms of what a threat can look like to you. Mostly for remediation though, the benefits that we see are, you can really quickly add to accept or reject lists various IPs that you see. You can also isolate suspicious workloads for further investigations. Those are kind of the big things that we see often with security in Ansible, but since it is a really flexible platform, it's really meant for creativity. So we have a lot of stuff out of the box, but really the sky is the limit if you're willing to put the work in. Yeah, I can imagine all sorts of things you could do if a threat is monitored or alerted on, shut down firewalls, ports, send tickets, everything from that, alert certain people. So it seems like, yeah, it's sort of the eye and the beholder, it's very open to whatever you wanna do in terms of remediating things. Exactly, kind of going back to the Star Wars metaphor, if you've got your command console in front of you, it's where you can see kind of the things that it really looks for to tell you about a threat. It also, you can set up playbooks to restart systems if they crash. You can back to create backups to keep things running. Like there's really a lot that you can do. One thing I do wanna stress is it is not a security operation center in and of itself. It's really meant to streamline what you have already. Like I'm sure you've seen some of the stats around, the average security team can only see something like 5% of the actual logs that come through and Ansible really helps cut out that noise so that they can see the things that are actually threats and then in many cases, automated response to it as well. Yeah, we had a question that Rashid says, anything you can do to prevent the threat, I think it means threat, the threat with Ansible. So are there things you can do to prevent threats? Assuming the same, yeah, absolutely. Remediation is really just a piece of what Ansible can do. It's also really good for provisioning and managing policies and stuff around firewalls, also around certifications and accreditation. So any kind of secrets you have or passwords or user management, you can do a lot of work around there to make sure that they're being rotated in a safe manner to keep some of those vulnerabilities from coming up. It also can help your firewall be more effective by putting a lot of those best practices in place without a person doing it all of the time. And that's just a couple off the top of my head, but yes, there's a lot of things you can do for threat prevention with Ansible as well. Yeah, you mentioned secrets, management. I think Ferris, that's what CyberArk is doing with their Ansible stuff, correct? Yeah, exactly, and that's a great point. So CyberArk puts in this secret management where if you have an Ansible, building your infrastructure, sort of speak after whatever event, whether it's a Cyber attack or whether something happened in your infrastructure rather than going in and manually after you build it, after you have Ansible build everything for you, you go in and manually change secrets into all your applications and all your infrastructure. Basically, CyberArk kind of goes in, integrates with Ansible and then rotate all the secrets for you, put all the secrets in, you wouldn't have to worry about a thing, kind of like cuts your time from however many hours based on your infrastructure to just seconds basically that goes with Ansible. And that link that we posted has a lot of information about that and how this would work. And again, CyberArk has certified an Ansible and they have spoken in Ansible first, which was a very good talk that they had and they showed that reference architecture in it as well. So I'll be sure to put the Ansible first talk as well. Yeah, and we've done joint workshops with CyberArk with the Ansible, we've done some OpenShift CyberArk workshops as well but they also have one for Ansible that I've known they've done as well. So if anybody's interested in getting their hands dirty, we've got a repeatable workshop to have you try it out. And I think you've done some work with them recently, right Emily? On certification? A bit, yeah. So we just finished a partner webinar series that they were a part of as well. So they talked all about a success story they've seen in the security space. So I think they go into that use case in more detail there. But yeah, they've been great to work with. Well, good. Jumping back to sort of Ansible generically, how if I'm a programmer or even if I'm not a programmer, how experienced do I need to be able to start using Ansible? Yeah, that's a great question. Really it caters to pretty much all kind of experience levels. So you can get all the way into the weeds. We've got a huge community in the open source space that works on Ansible as well. It's got a lot of really experienced experts that do really cool things with edge cases and use cases and stuff. But with our still relatively new content collections and the way that Ansible is set up with using primarily YAML for most of its playbooks and modules, it's really easy and readable for people joining the first time. So it makes it really easy to understand kind of what you're looking at and what it will do. So you can kind of get started right out of the box, but also sky's the limit. The more you do, the more experience you get, the more creativity you, yeah. I love that it stands for yet another markup language, a sucker for self-explanatory acronym. But point being kind of anywhere in the spectrum, if you're just starting out, it's really easy to pick up. That's one of the strengths there. But the more you do, the more you can do.  There's so many examples out there. I've developed a couple of workshops for Red Hat, one of them being CyberArk on OpenShift and the backbone of that automation to deploy CyberArk on top of OpenShift and we're working on a same sort of repeatable workshop with Ansible is Ansible. It's a playbook that runs and deploys things on Kubernetes or deploys things in Tower. So yeah, very, very simple. A lot of good examples out there. Yeah, I was gonna say, I think we have like a combined use case where we use OpenShift and Rackam and Ansible and I think CyberArk as well, kind of managing all those secrets together. So there's a lot of overlap there. The whole benefit of automation really is best when it's invisible. You set it up and then it just works. Very cool. I'm posting Ferris wanted to post the Ansible channel for everything Ansible. What are folks gonna find in there? Except Ansible. Ansible, Ansible, Ansible. So they're gonna find the word map. This is the Ansible channel actually and you can subscribe to it and then you will see everything that happens newly that's been introduced with Ansible. It talks about the word map. It actually has a recording for the word map for the 2.1 that you'll be able to see there and learn more about and you can learn about the certification that some of our partners would do and how they can do it and then how customers would be able to utilize all the new things right off the bat. Now, as some of you know, we are currently in the 1.2 and this is a 2.1 release. So it's a big deal. Has a lot of great new things that are very, very usable that has been done over research of a couple of years now and some of it would apply to edge computing. So this is really all that information you find it in this channel. I'm seeing in chat, it looks like that's only, it's a red hat internal link. What was the internal link? I don't know if that specific one is also external but I know that there's also a YouTube channel. There's ansible.com has a whole mess of documentation and courses and everything you could desire. This is a live show, so there you go. There you go, that's why people like the live show just could go on and let me go. And our audience is not, is just, is other people in red hatters? Yeah, we'll share the external one and also folks were asking this, where's the partner seminar I can watch? So either Emily or Ferris, if you would mind getting that external link as well. And- Yeah, Jeff, Ferris, do you have that one on hand? Yep, I'll use that. Well, as soon as you get to it, have the ansible channel. I know I have it somewhere but it's lost in my forest of tabs. Cool, yeah, we do have an IBMer on here who's related to us but can't get into the internal red hat stuff. So yeah, we'll get the external link for you pretty soon. There is, we've talked a little bit about use cases, right Emily, was that the main use cases or were there others around ansible? Yeah, those were the main security ones. I know most people that would be familiar with ansible already probably think of us in like the infrastructure space. So we've got all those security ones as well. We also have stuff in the network space. So there's a lot of like compliance enforcement, security orchestration, vulnerability remediation stuff along those lines. And we're also going pretty heavy into cloud stuff as well. So there's a lot of provisioning and configuration management and stuff there as well. But like I've said before, you know, it's automation. So sky's the limit, but those are where a lot of like our prepackaged kind of best for beginner collections and content are. Cool, yeah, thanks Ferris. Posted the YouTube ansible channel which has that information that was in the internal link. I just posted the ansible use cases which we talked about. So the three main ones, investment enrichment, investigation enrichment, threat hunting and incident response. There's a couple of good videos actually. I really enjoyed those videos. And then you can see how ansible can work with different tools, firewalls, intrusion detection, seams, pans, EPPs. So that gives you a good understanding. And then you should be able to find a workshop in here somewhere if you're interested as well. Cool, there is another use case that I'm not too familiar with around OpenShift and Rackam. At a high level Emily, could you give us a little bit of understanding what that use case is? Yeah, for sure. I think there was a link published around there. I can see if I can track that down. I found a video. I stumbled across it a couple of weeks ago. That was pretty cool. But really kind of what goes on there. Since I'm ansible, my understanding of OpenShift and Rackam helps you manage multiple clusters at scale across hybrid cloud environments, et cetera. But at its core, that's the focus there. And what ansible helps with the most in that kind of use case is bridging that communication gap between the traditional kind of ecosystem that you have and the cloud native experience so that they're all speaking the same language. I think is really the basis of the most common ones we see there. I'm sure there's more, but off the top of my head, that's the one I'm most familiar with. Yeah, me too. And of course, who would have Kubernetes and legacy software? Nobody has that one. Everybody has one or the other, right? Hybrid cloud, no hybrid cloud. Well, good, yeah. And I think that was announced recently, relatively recent, which I think about six months ago, it's relative. Everything's kind of a blur in the pandemic times, but it's a relatively new offering. And obviously we'd love to hear feedback if folks are using that or if they're interested. Well, cool. Let's talk about partners for a little bit and ansible and certifying, how would a partner become a partner of ansible if they wanted to? Yeah, and I am very biased, but I recommend it. So it typically is the same process as becoming a partner for any other Red Hat product. You start with connect.redhat.com. There will be a fairly basic legal agreement, just making sure that you support any content that you contribute very normal open source kind of stuff. Once that happens, once you're a certified partner in the connect space, then you can email ansiblepartners at redhat.com. We'll help you get set up the rest of the way. For the most part, it's a pretty simple process once you're certified in the Red Hat area for creating certified collections, which are the ones that show up in Ansible Hub. So for Ansible subscribers and customers of Red Hat, you create your content like always. Often it will be on Galaxy, the upstream open source version as well. You run it through my team, partner engineering. We run some basic tests, very similar to what we do in the community. And once it passes, it's uploaded to Hub and any of our joint customers can use them. All right, so what are some of the partners that you've worked with recently? Yeah, I know we've mentioned CyberArk. They've been one of the first partners that actually went through the whole process for real. So they've been around a long time. We've also got collections with Splunk, Syncope, Checkpoint, got a few Cisco ones in the security space as well. I think those are the big ones so far, but I think you can see a list of all of them on Red Hat as well. Or if you're in Hub, you can check out the collection sites. Cool. So Andy said you had one with Cisco security as well. There's a few collections from Cisco. Some of them are in the upstream area. We're working on getting those certified as well. I think we primarily have collections with them in more than networking space, but security is in the mix as well. Oh, cool, awesome. I'm gonna put you on the spot here, Emily, I didn't prep you for this question. If somebody's done with an Ansible collection, how long does it typically take to get that certified with Red Hat? I have graphs, I won't show them to you, but typically once your collection is done and ready, the testing process is pretty simple. So as long as you're responding to emails, typically it's a week or two, kind of at the outside, but if you don't do your part, it will take much longer. But typically it's a fairly quick process. And some of that is because of the way we changed collections, I think a year or two ago, it used to be you had to wait for a major version of Ansible in order to change anything, any of your content. We've separated that out, so now they're in-hub and they're their own thing, so you can upgrade, update, iterate your collections anytime, completely independent of our release schedule. Oh, yeah. So, well, that's a good question. So we can go as fast as you can with the minimum of a week, right? And the certification, and then once you are certified, what do you get out of the certification you get? What do we feature you in our website like we do with OpenShift and things like that? Yeah, absolutely. Co-marketing is one of the best benefits that you get through the partner program. If you have certified collections with us, you have access to all of our Ansible community, all of our Ansible subscribers, see all of your collections. Also, like any of our Red Hat certifications, you get Red Hat support. So any issues that arise with any of your collections, they go through Red Hat support first. So you can be sure that the only issues you get are ones that you actually need to pay attention to. Nice.  So that's kind of the biggest benefit, like with anything Red Hat, it's your, you got your support, your stability, because things are more vetted and tested and have, you know, a little bit more scrutiny on them. And especially for the bigger enterprise businesses, where it's more difficult to move quickly, it does tend to lag a bit behind the upstream community, a lot like Fedora versus Rel. So you have more time, more support. And the third thing that I forgot that I listed, more stability. Well, that was the second one. I got there. It's done. Yeah, so that's good. You know, I love the fact that they can display, like cyber art, they display the certification badge. So then all of these things, they, by transmission, they go into the customer's mind, but they see that it's a certified, they see we work with our partners and you get this piece of mind that would give the customer, the partner and Red Hat feeling. Exactly. Yes. It must be win, win, win for everyone. Three wins. Cool. That's some good chatter going on. One thing, Ferris posted the Ansible Fest session that we had with cyber art. Actually, you know, Dave, I think that you get the chat. So if you don't mind posting it by proxy, because you- I did. I'll put it in there. Okay. I believe I did, yep. It's right there. And then some good chatting between Rashid and Carlos. Rashid mentioned Ansible has really made OpenShift deployment easy, but it's a little harder to get right on the first run. So have you seen a lot of customers use Ansible for OpenShift deployments? I don't know offhand how many. I do think especially with that feedback, it does make it easier, especially if you're going to do anything in kind of a repeated way. Like with all things automation, it's a little bit of that upfront work for a lot of save time over, you know, the long term. Yeah. Yeah, and Carlos was mentioning, you know, uses Ansible to configure host VMs. He prefers GitOps though to do, to open, to install things on clusters, which GitOps does very good job of it and has its own use cases, because it can, as Carlos mentioned, know about cluster config drift. But he also says that uses, let me show this, for see how you can run Ansible protect on pipelines. Which is cool. Cool. Any other questions from the group? Feel free to add it to the chat. If not, I think we've had a pretty good discussion here. Is there anything else, Emily, that you wanted to mention about Ansible or discussion? Nothing too big. Just like if you're not a partner and you're looking to be, feel free to reach out. We're always happy to get more. And look for more stuff coming with Ansible platform too. Awesome. You'll definitely do that. Ferris, any closing thoughts from you? I think that was pretty good. I really liked the fact how some of the interaction with the group would put an Ansible to deploy OpenChip. Great idea. I actually, I haven't thought of that one, and but I think it would be a great thing because you could put in development and deployment. You can just repeatable actions. I think we covered a lot of things with the certification. The certification is really good. We know where to start, Emily. And with Ansible Fest, looking at the cyber arc integration, this is what I would recommend for you as a customer, as a user to start with. If you're looking at secret management, I know that cybersecurity is in everyone's mind these days, especially with the executive order. If you're looking for a zero trust strategy, you know it all starts with identity management and so on, cyber arc is big and identity management but secrets is a pivotal factor in doing that strategy. So it'd be great idea to take a look at it. So, but I think all in all, we had a great discussion. Just you know who we are. So if you have any questions after the show, please don't hesitate to reach.  Awesome. And one thing I do want to plug for my solution architecture team. Anybody's curious, the shirt I'm wearing, it's called Davey Street Enterprises. This is a fictitious company that my team has blogged about. And I'm sure there's definitely a couple of blogs in there about Ansible and about how this company called Davey Street Enterprises has transformed their business using Red Hat technologies. So it's pretty entertaining. There's a lot of neat characters in there. My favorite is Zachary Trudeau. That he's the security guy. He's Trudeau is actually Mr. T's actual name. Anybody cares. But it's a good, it's a good several, let's say about half a dozen or so blogs and we're about to round it out here this at the end of the year. Yep. I'm a reader of the blogs, Dave. Can I get a T-shirt? Yes, I'll try to get you one. I never have too many T-shirts. That's why it's always good. And with that, I just want to post again the, see if I could post this. Oh yeah, there it is. The schedule here. This was the framework, but the DevSecOps is the way monthly series. We've got another one coming in December around platform security. So that's all gonna be about open shift security and things like Linux security, SC Linux, SC comps, really cool stuff. So look forward to that. We've got all this stuff posted from all the content we've done in the past. Check out catalog.redhat.com podcast for our podcasts, live streaming shows. And then I put the Ansible use case security automation. I posted that in the chat as well. But if you want to read more about DevSecOps at Red Hat, there's a lot of material. Just go to red.ht. Ford slash DevSecOps to learn more. So with that, I want to thank Ferris and Emily for joining me today on DevSecOps is the way. Really appreciate the conversation. It was great. And I will say goodbye to everybody. Have a great day. Thank you. Thank you, Emily. Have a great day. You too.


The following is a production of New Mexico State University. Human nutrition classes using computerized diet analysis have come a long way from the early cooking classes taught at the turn of the century at New Mexico State University. The home economics curriculum at what was then called the College of Agriculture and Mechanic Arts reflected the times with classes in special dressmaking, millinery and art needle work. As a crisis years of the Depression and World War II changed society, the curriculum also changed to stress family care, food preservation and nutrition. In 1953, New Mexico State University established the innovative O'Loughlin House, a live-in laboratory giving students first-hand the experience of home management. Today, home economics has expanded to include consumerism, fashion design and even restaurant management. For the early years, I'm Carla Aragón. This was a Centennial Minute from New Mexico State University. The preceding was a production of New Mexico State University. The views and opinions in this program are those of the author and do not necessarily represent the views and opinions of the NMSU Board of Regents.