AgentsInTheCloud - Security and Secrets

All right, let's talk about security and secrets.

And how should you be thinking about security in the context of edges in the cloud?

I guess I would start by saying, like, it's way, way, way, way, way safer than running coding agents on your laptop with your family photos, credit card and everything just there for the taking.

your agents run on, the server that you install agents in the cloud on.

but it's also no Fort Knox, and it's not perfect.

And the way I think about security is that you're supposed to have the security boundary on the outside of the application.

So you need to make sure that only the people you trust can access it.

And that's how it also installs itself by default that it access through your tailscale network.

there's no users, there's no accounts.

If you can access the machine that it's running on, you, can control them.

within one installation, there is separation between these workspaces, that makes it very hard to accidentally leak stuff from one workspace to the next.

however, if you put a hostile, agent in the workspace and you ask it to break out, chances are it will eventually find a way.

So depending on the sensitive nature of the stuff you have, it like you might or might not want to put different projects for different employers or different clients in the same installation.

It depends on your appetite for risk.

Again, it is way safer than doing it on your laptop.

and it's very hard to accidentally, to sort of, you know, to accidentally, reach into another workspace.

But with enough, you know, like, agents can do a lot these days and yeah, so you should treat the security boundary on the outside of the application.

that said, I also don't like to make it easy to have, you know, to, for your secrets to leak and stuff like that.

So I want to talk about how secrets work.

let's start with a GitHub secret.

If I echo my GH token here, you'll see that you get this super weird value, atelier proxy ready GH token.

if you were to send this to actual GitHub, it would yell at you.

But if I do it, GH of what is it?

Status, GH of use or status user or something, then it works just fine.

And the reason it works is that all the outgoing network traffic from this workspace goes through the agents in the cloud proxy that is also on your machine and it scans the network traffic.

For this guy being used and if it sees it, it swaps it out with the actual token that is hidden from the agent.

we have that for GitHub, but we also have that for your own things.

If I go in, here I can go to my secrets and you can see I have a GH package token.

I can add a secret and I can say that, well, this environment variable, when you see network traffic going to this host, then you should replace it with this value over here.

so that's like a man in the middle secret, injection situation.

again, I'm sure there are models out there that if you ask it to exfiltrate the secret, they will hack through the Linux kernel, they will find some exploits and get it anyway.

but it's but you cannot get it sort of like easily, or by accident.

And we have a similar setup for SSH keys.

one thing I love to do is I ssh from a workspace into other computers.

Maybe like I have another Mac that I use for iOS builds and simulators and I put a public key on the other machine and then I put the private key here.

But I don't like to put it in a place where the agent can see it.

So you see, I have a release helper and a remote Mac.

You can add a secret here, sorry, an SSH key.

And then if you use SSH from within the workspace, that ssh, it never gets to see the actual private key, but it's able to authenticate using the private key, regardless.

All right, that's it.