0:00 Introductions

0:00 Hi, and welcome to AlphaBits. AlphaBits is an outlet for our inquisitive minds. We can't stop experimenting with new technology, and we wanna share what we're playing with with you. We're your hosts, Brian and David. Hi. I'm David, defender of the Rawkode Academy. I'm a perpetual learner, always playing with new cool tools that I'm gonna share with you as part of this podcast. And I'm Brian. I'm a developer advocate at Amazon, and I love all the shiny new toys in tech. It's kind of my passion is is testing out the new stuff and, seeing what's cool. So I will start the

0:36 demo joy by sharing my terminal. So this is, and there's no graphical interface to this. It it's only a login shell on my laptop. And if I do something like l s v l k, you can see the USB key that it's booted off of, and then the physical disk that have been claimed as, persistence data spots for, Lightwhale's Docker container. So it it keeps, Docker images on one partition and persistent data on another. And so when I reboot, it will still boot off of the USB key, but all of my Docker container stuff is

0:40 podmansh

1:20 in it's on the physical disk. It's a really neat way to do things. So let's just look. Again, this is BusyBox, so there aren't a ton of things on the host when the the operating system itself is tiny. And I have a Docker Compose directory here. And inside that are all of the things that I run internally for my my own bits. I've got Caddy as my reverse proxy. I've got Coder for coding environments, Paperless NGX for document storage, syncing, and vault warden for pass password sharing. So if I c d into one of those, like, caddy

1:39 Lightwell: Setup and Persistence with Docker Compose

2:01 and show the Docker Compose file, you can see that we've got my Docker storage set to home op persist. So any data that is in the container will be in a completely different directory on the host, which I can just back up, which I do just back up. And I can just do doctor compose stuff like normal. And you can see the logs for caddy. You know, nothing exciting is going on there. So this is actually really exciting because it's it's the lowest footprint you can get for a hosting environment. I mean, there's really nothing

2:34 Lightwell: Advantages (Low Footprint OS)

2:42 nothing you could do that's smaller than this operating system. And the the point is that you don't really have any system updates to do because you've got a stable kernel. You've got a stable version of Docker. And so the only maintenance you need to worry about is keeping your containers backed up properly. So it's super exciting. And I've been using it for about a month now. I worked with, the developer to, get NVMe support because the scripts originally didn't support NVMe disks. So I submitted an issue, and and he got that fixed up later. So this is, it's called Lightwell. And

3:17 if you just Google search for Lightwell, you can find it. Super awesome. So that's demo one. Let's go to demo two. So this is, I'm testing this in a virtual machine on my host. So this is just a a KBM virtual machine with another instance of Bluefin. So let's log in as me, and let's show off the interesting bits here. So if we cat let's see. Password. You can see that I've got three extra users created here. Locked user, confined user, and full user. And those are demo users to show the different levels of isolation that you can get per

3:26 Brian's Demo: Podmansh Overview (Containers as User Shells)

4:04 container. So locked user doesn't have any access to the local disk. The only thing that that user can do is touch the storage in the Docker volume that's assigned the container volume that's assigned. Confined user has access to their own directory, their home directory, but can't do, anything else much at all. And then full user has access to, becoming sudo and doing root things and also has persistent disk storage. So if I change to root here Let's go to Var Home. You can see the three users, the full year, and I'll show you how we set this

4:51 up. So if we go into config containers system d, there is a container definition file. This is a quad lit definition. This is a Hat labeled, docker compose, layered on system d. So let's PI that. And what we could see is it's a standard system d unit. Before it starts, it's going to make the user's data persistence directory. It's gonna run the image container image for the word toolbox, name it podman s h, and this is important. Remap users inside and outside the container because podman's rootless. So this is using c groups to maintain the

4:53 Podmansh: Configuration with Quadlets and Systemd

5:35 user ID and group inside the container. I have SC Linux disabled because I don't have it working yet, I don't know how. So that's a study issue for me. Running it means it's gonna run-in system d, and we're gonna keep the data directory at the home, and the capital z is a SE Linux labeling attribute. Workdir's home directory, and what it's gonna do is exec sleep infinity. So as soon as this person logs in, this the container will start, and the this will just keep the container running while the person's logged in. I also set the network level to host so I

6:19 don't have NAT and contained networking. So that's all I have to do for this user. And then if you look at the key password, you can see that the user's login shell is set to user bin, podman s h. So that's it. We we defined a container that's gonna be this this user's login shell, and I can do So how do you configure the difference between the full user and the contained user? Like, where is that configured? So that is that's actually all in the container file we just looked at. So the podman arcs and the volume, you would change those

6:49 Podmansh: Isolation Levels Explained

7:03 to, to different levels. Like, we look at, go to the docs, documentation, search for podman s h. But this one page, by the way, is all of the documentation that exists, one man page. So, they've got some examples on here that show the various levels of lockdown. So the first one, the locked u, has absolutely no access to the host OS, and it drops all capabilities, no new privileges. You know, this is a completely locked down and secure user environment, which is, you know, good and bad. You're not gonna get a lot done in there,

7:46 but, you're not gonna get a lot done in there. So that's good. Then the confined user uses, remap users. So it keeps the user ID, and it has access, same as you would on the host. So you can have data stored in local disk that appears as your home directory there. And then the final one, and this is the example that I'm roughly based on, but I can't get all of this SELinux stuff to work because SELinux is a mystery to everyone. So this one is also running in a container, but it has, the ability to

8:24 escalate to root, and it can run containers inside the container. So it can it can run nested containers, which I haven't got working yet either. So let's let's try to SSH as that user. So we'll SSH full view at localhost. Set the key, type in a password, and it blows up. It broke. Don't know why. Let's find out. Why? Maybe try a different user. Oh, there you go. Oh, there we go. I got one that time. So who am I? I'm full u. And if I c v to my home, I'm at var home full u. Let's

8:41 Podmansh: Live Demo - SSH and User Environment

9:38 l s. So there's a file called some file. Let's I don't even know if the I exists. Alright. So now if I s u, You can see that, some file is not here. It's actually in the data directory. So when I am inside the container environment, my home is this data directory because that's where we set it up in the, the container quadlet definition. So I can do, some pretty cool stuff, like change the container. Oops. Too fast. I don't have the keyboard here. So right now, it's running Fedora toolbox, but what if I wanted to run a completely

10:40 Podmansh: Changing Container Image

10:48 different container? I don't know if there is an Ubuntu toolbox in that registry. Let's let's look at my host and get a good example. So there's an Ubuntu example we can use. Well, let me. Alright. So we'll change this from a Fedora to Ubuntu. And now if I log out, log back in. So do you not need to restart the system d service? Nope. Because it's it's really a a daemon it's a login shell. So it it container stops running when you log out and starts running when you log back in. Okay. So now I could cat

11:46 OS release. Oh, yeah. And you can see I'm running Ubuntu now instead of Fedora. Neat. So if if I had it set up, I could do apt update, apt install things. That's one of the sticky parts right now is that the user management is on the host operating system, and it doesn't doesn't copy in like this Etsy shadow. So I have to reset my username and or my user password in order to get root access. And I have scripts to do that right now. I'm hoping there's some way I can change the init system to do that automatically,

12:23 and then this will become a pretty neat tool. So that is my demo. Completely contained user environments in containers. And the last bit to show you is, oops, is that this is not just at the level of terminals. If I log out, I can log in as that user and get a desktop environment where everything is still contained. So the terminal and and I've got my Oh. Ubuntu environment, but I'm clearly in my Fedora Gnome window here. So pretty slick. I'm I'm excited to see where I can take this. I'm sure I can abuse it a lot.

12:29 Podmansh: Desktop Environment Integration

13:17 Question is, will it be practical and useful to do so? So that's my demo for today. Very cool. Alright. So you should be able to see my web browser. This is Infisical Cloud. So everything is open source to remember, but I have set a few things up just for the demo today. So I have an organization called Rawkode Academy where I could invite people. I have a project called Rawkode Cloud. And if we explore that, we can see the different environments that have been configured. Now these are arbitrary. They don't need to be dev staging and prod, but, you know, that's what

13:41 Infisical: Web UI - Managing Projects and Secrets

13:52 they are out of the box. You're welcome to tweak it. What's nice is that we have these two properties, cloud dev name and password. We can see that they're set in dev, but not in the staging and production. So, you know, we could go into here and start to provide those values that we wanted, or we could just explore dev and we can just click and see what the values are. So from a perspective of managing secrets, you just add stuff in the web UI. One, three, a, b, c, and then click save. These are all very much like get and

14:28 that you can well, I guess on the cloud version, we'd need to host it ourselves. But you can see the differences there's a complete log of the changes. We got the other log over here. So now one of the things I like about the cloud version is that it has all of these integrations. So one of my pet peeves just so you know, it's nice to keep secrets in one location, but you always need them and third party services like GitHub actions. Right? We wanna be able to get our secrets in one place over there without having to do,

14:44 Infisical: Third-Party Integrations (e.g., GitHub Sync)

14:59 like, a dual commit and update them in multiple places. With this, you can just click integrate with GitHub. It'll actually still approve the app, and you can tell it to sync this project to a repository secrets in GitHub. And then whenever anything changes here, it automatically updates GitHub for you and they get the new credential, which is also a nice touch. So let's drop down to my CLI where we can run-in Physical run, and I could run a print end where we have one environment variable called cloud dev name. And this will automatically be injected, and then

15:23 Infisical: CLI Usage for Injecting Secrets

15:36 it prints out here. We can also do the same for password. So the idea being our workflow becomes, you know, NPM run dev or whatever the command is or, you know, for the Go developers, go run main.go, etcetera. And all you need to do is prefix it with this Infisical run, and your environment is automatically injected for you, which is pretty cool. There are a couple more things that you can do. So if we do Infisical help, they have a scan command, which will actually scan your get history and any files in the local directory to see if any of

16:09 Infisical: Secret Scanning Feature

16:16 your secrets have been committed now or even in the past and give you a way to kind of, you know, you just have to know that it's been committed to kinda clean up and rebase and get rid of all the bad stuff at some point. So the way that this works, I ran Infisical run without specifying, like, the project or the environment or anything, but everything is just inside the JSON file. Okay. So this workspace ID is actually my Rawkode cloud project, and I've set the default environment to be staging. And you can tweak that to your parts

16:46 content. Oh, nice. And you can change environment by changing to a different Git branch too. That's like Yeah. So you can have it. Like, if you're on the main branch, then, you know, it's probably gonna use your production environment if you wanted it to. And if you're on the dev branch or non main branch, then it can use another environment. So there are lots of little things you can set up like that. The the whole web interface, it's quite nice. You know, it's got things that I haven't seen in similar solutions like this folder approach. So, like, from here, you can actually

17:15 Infisical: Organizing Secrets with Folders and Referencing

17:17 say that you want to create a new folder and these work like a let's call this sub project. Like a namespace? Yeah. So we can now come into the sub project. There we go. And we can now add more secrets at a different level. So we get a password, b b c one two three, and save. So you can give people access. So it's kinda like a security boundary. I could say that you only have access to the subproject secrets, whereas I would have access to all of the So it you know, if you got a model

17:52 repository, for instance, this would be a good way to do it. Or if you just want to separate concerns, maybe you've got, like, AWS secrets, Cloudflare secrets, and you wanna just contain them all slightly separately, then the folders are are quite a nice way of doing that. And they also implement one of my favorite features from Doppler, which is secrets referencing. So if we come into the subproject, we could say root secret, and then that can actually be a reference. I'm not gonna be able to remember how to do this now. Let's see. It's something like

18:31 secret, and it takes a full path within this project. So we could say something like that. So you can reference up and down the stack. You cannot reference across project, which is something that Doppler does quite well. But I think I kinda prefer the approach that Infisical have taken with it. So I just think it's a cool project. You know, full disclosure, it's not something that I'm running for any real project yet, but I just think it's something that I may use for secrets management moving forward. So I'm still fully in the one password camp right now, and I use the one

19:07 password still live in a very similar fashion. But I do like the integrations that they offer to sync to GitHub, to Cloudflare. In fact, if we look at the integrations, it's pretty vast. Right? So you can go to AWS secrets manager, CircleCI, GitHub, fly dot I o, which I'm starting to use a bit more. Cloudflare pages, I use I use an awful lot. And then, obviously, Terraform cloud and stuff. So it's just it's just new. And the last thing I'll say, these framework integrations are fantastic too. So, like, even if you don't want to run Infisical

19:36 Infisical: Application SDKs for Direct Access

19:40 run on your CLI, you can actually just have the JavaScript SDK pull secret out within the code if you're Oh, wow. And as long as you have a service account token to speak to Infisical, then it will just work. So that's another pretty neat way of doing it as well. I wonder if there's a quick code sample I could show here. Where's and React should be enough. Nope. Framework integration. I'll go next. Nope. Nodeto.net. Am I not seeing something here? Where's the code? Never mind. There is a complete SDK. That's awesome. I just put the Cal node there.

20:26 I feel like I have to find it there. There we go. I was on it recently. So yeah. So you can just create your client, and they have service account tokens so you don't have to pretend to be a person. And then you just say, hey. Get my secret, and then it's available in your application. So, yeah, really cool project. And then hopefully, get more stuff or get some stuff moved on to it at some point. I love it. I'm 100% gonna self host some of this. Yeah. I believe the requirements are just it's a Node JS TypeScript application.

20:43 Infisical: Self-Hosting Options

20:55 It requires a database, which is MongoDB. And as long as you satisfy both of those, then you have a fully managed secrets environment that you can run anywhere. They actually have a starter thing. So if you come to Infisical on GitHub, they have like a one click deploy to EC two and Digital Ocean as well. Wow. Very cool. Nice. And they can self host with Docker Compose, so I'm gonna go put it on my Lightwhale box. Yeah. I was I was considering doing a Docker Compose up as part of the demo and I thought, no, that's not important. Just

21:30 show the product. So there we go. Very sweet. Good demos today. Yeah. I think I'm gonna have to go a bit more alpha for the next one considering you showed two things that have barely any documentation. You've got things with docs and, you know, Docker Compose files and, you know, that way too beta for me. Let's get get a little deeper here. It's still a 0.9 release. So, you know, it's it's still very early but the you know, I think that project's been around about five months now And I think they're funded. I think it

21:34 Discussion and Conclusion

22:04 took off when people seen it and as they're now trying to build a business around it. So best of luck to them. Yeah. I love this. This is great. Gonna make some. Alright. Awesome. Good week. Well, that's I like this one. Yeah. See you next week. Cheers. If you wanna hear why we showed off these tools, check out the podcast available at alphabets.fm. Until next week, see you soon.