 Awesome. We have Ashley here who will be presenting on how to use sensitive data in containers. Perfect. I'll share my screen, share the video with you. Hello and welcome everyone. My name is Ashley. I'm currently a software engineer at Red Hat working on container engines. Stuff like Podman, Builda, sometimes some other projects, but mostly Podman and Builda. I'm here to talk about using some sensitive data in containers. So what is exactly sensitive data? Sensitive data can be really anything, but some common examples of them would be usernames and passwords, TLS certificates and keys, SSH keys, but basically anything else you know that other people shouldn't know. And sensitive data is kind of necessary for a lot of applications that you're going to be using inside a container. You could have a username and a password to a database. You could also need a TLS certificate and some keys for a web server. And maybe you're using SSH to push and pull from GitHub. In that instance, you would need an SSH key. So you can see that sensitive data is actually quite frequently used, but there's a problem, which is sensitive data is sensitive. You don't want other people to know it, but you do want to inside your container because you are going to be using it. So let's take a quick look at the options we have to getting regular data, any data inside a container. You could mount in a file that would work as data using our dash dash mount flag. You could find out something into your container. You could also use an environment variable using our dash dash env flag. You can set anything to an environment variable. But if you do choose to bind mount or set something up as an environment variable, your data could end up in other places. If you bind mount to file in and you do a podwin export, it just means that the file that you bind mounted in that might have sensitive data would be exported into the tar ball that you're exporting to. Same scenario for podwin commit. If you commit your container into an image, the file of the data would be committed there, and God forbid you push your image to a registry, all of a sudden everybody has your sensitive data. And of course, if you're passing in args using your command line, it can show up in your terminal history, and it will be visible by a podwin inspect on a container because it will show the command line argument that was used to create the container. So here's where secrets come in. Secrets will allow you to use sensitive data inside of a container or a build with added protection that prevents your data from escaping to somewhere that you don't want it to be. By its implementation, a secret will never be committed to an image and will never be exported to a tar ball. You're also not just putting random data everywhere, I'm just putting it into your container. Secrets will help you centrally manage all your data in one place with the easy podwin secret command. Personally, I think it's pretty elegant and easy to use. So now that I've effectively hyped you guys up, I hope for this great secrets feature, let's see a little bit of a demo starting a demo. All right, here we go. So let's start off with something a little bit simple. We'll create a podwin secret and then mounted in with some other options like UID, GID and mode. So let's first create our secret. First, I do a podwin secret create my secret. My secret would be the name of the secret and the dash just means read the data from standard in. So in this case, it would read the hello from the echo hello that I'm piping it into. Now that we have our secret created, we can run a container with that secret inside of it. We do this by using the secret flag in a podwin run. The source of our secret is my secret, which is the secret we just created. We're doing a mount type secret. We're changing the UID to a thousand and the GID to a thousand and one and the mode to 777 to just, you know, spice some things up. And then we'll just look for the secret and run secret slash my secret. That's just the default location that secrets are mounted into. And there we go. Looks like the secret is there. The UID, the GID and the mode are all correct. Let's see what happens when we try to commit this container with the secret inside of it. Okay. So it's committed. And now we brought another container using the image that we just created. And voila, you can see that run secrets my secret doesn't exist in the image that we created, which is exactly what we want. Our secret is safe. It doesn't go anywhere else. If you accidentally push this image to a registry, you won't have your secrets go everywhere. You might have noticed that previously I was using a mount type secret. Podman also supports environment variable secrets. Podman has this cool feature where when you create a secret, you can actually read it from an environment variable. Last time I was reading from standard in, you can also read from a file on your desktop, plenty of options there. So yeah, using the dash dash in reflight just means read the data from an environment variable. So now let's run a container using the secret we just created. And let's make sure that this secret inside the container is an environment variable. So now you see that the type in the secret is an environment variable. So we do a print ENV and say we want another secret environment variable. And you can see your data, your secret data ABC is in the container. All right. So let's clean up some stuff and then do something a little more complex. The stuff I just showed you is pretty trivial. Just demonstrates how it works. But I want to show you a more realistic example of how you would use a secret inside a container. In this example, I'm going to show you how to deploy an nginx server, a web server that has a CA and TLS certificate and key. I've gone ahead and already generated a root CA and TLS certificate and key, as you can see on the screen in my files. So now I'm just going to take their generated keys and then store them in our podman secret function. All right. Now that that's done, let's create a container. We can see that we're adding three of our secrets, our key, our certificate and our config into an nginx container. We're exposing or publishing our port to 3,000. And we're linking our config file just because nginx expects it in a certain place. Let's start our container and make sure it's running. All right. And then let's pull up a browser to see what's going on. Going to local holes 3,000 and we see the web page is up. And let's check the certificate. There it is, the podman test certificate that I had generated and put in the container. So now that you've seen podman secrets in action a little bit, let's talk about how it's done. The central secret storage, so the podman secret command and anything that has to do with it is extendable. It's written as a driver. So if you had a secret store that you want to use already, you can write a driver interface to plug right into podman. We do have the option of using a pass driver, a go pass driver as a secret backend, but currently the default is an unencrypted file driver. So actually your secrets will not be encrypted on disk. Of course, in the future, we're looking into doing something encrypted. That's much more secure. The reason why secrets won't be exported or committed is because the secret is binemounted in as a tempfs. If you're using the mount type secret and if you're using an environment variable type secret, it's a special environment variable that's kept separate from other environment variables that are guaranteed not to be committed into an image or exported as a terrible. So I've shown you all about secrets in podman, but recently we've also put secrets into build up. It works a little bit differently. There's no central storage like podman. It's just one command, but it's still pretty interesting and I'd like to show you how it works as well. This is kind of confusing because the purpose of build is to build an image and so why would I be using a secret if I don't want something to be in an image, but build is making an image, like what's going on there, right? Basically for some commands in build, some run commands, you might need some information, some sensitive information that you want to use only during the build. The secret still will not end up in the image. That will not happen. That's the point of a secret, but you might need something during the build. So the syntax in build is a little bit different. Half of the secret syntax is in the Dockerfile and half of it is in the command line. You can see the Dockerfile that I have right now. I have two run commands or sorry, container file. I have two run commands. One has the dash dash mount type equals secret and we're counting that secret. In the second one, we have one without the secret. We're just counting my secret. I also have this file called my secret with literally some secret data inside of it. The syntax is a little special here. You can see that we're using the dash dash secret flag with the ID my secret. The source is the my secret file that I just showed you with some secret data inside of it. Basically the container file ID my secret references the ID that you're passing in via the secret flag and that's where the file is read from. Now we see we end up with an error. Don't panic. This is correct. You can see that on step two of three we're using the mount type equals secret and we get the some secret data, which is what we want. We want our secret in that run, but on the second run or the second run, the third step, we didn't use the mount and we can't access the secret that we mounted in the previous run, which is good because we only want that secret to persist for that one run. That was the end of my little talk on sensitive data and secrets inside containers. I'm going to turn it back to live Ashley. If you haven't noticed, this is prerecorded. Live Ashley will handle questions, comments, concerns and discussion, suggestions, anything about secrets that you would like to see, anything else. Back to her. That was my presentation on secrets. As I said in the presentation, secrets are currently unencrypted, but we're looking to add encryption into secrets. If anybody has any questions or ideas regarding encryption or any other ideas around secrets, please feel free to let me know in the chat or otherwise. Hey folks, if you have any questions for Ashley, please post them here in the chat. The chat should be available for the next 20 minutes or so, but after that we can move the conversation to the breakout room. I accidentally dropped, that's my bet, but if anybody doesn't have anything, it's just kind of a short presentation. There might be a question. I don't see anything in Q&A. It says, aren't the YAML files used in the demo available on the GitHub repository or other sites? I don't think that was for me, because it was asked three hours ago. But if you want the demos, I can post them. Could you add your demo or slides to the shed.com where you added your presentation or information? Yeah, I submitted them before, but I can add them. If you have submitted them already, you should be with them. Okay, I think I might have. I'll take a look at that. Perfect, thank you so much. If there's nothing else, then I guess I'll give you guys back your time and for you guys to get ready for the next session. Thank you so much. And then if you have any questions on anything Podmium Builds, feel free to contact us on our Podmium GitHub or on Twitter. I'm on Twitter at Quikodes, C-U-I-C-O-D-E-S. So yeah, that's it. Okay, thank you.