 Good. All right, am I good to start? Hi, everyone. So it's such an enthusiastic crowd. How's everyone doing? I like you. You're participating. So today I'm here to talk to you about kind of modern security practices and codifying security. So my name is Seth. I'm a developer advocate at Google Cloud. You might recognize me from the Hashi Group community or the Chef community where I worked previously. And to start today, there's some slides in the beginning. And then most of it's live demo, so that's exciting. But first, I want to talk about traditional security. So this is how I describe traditional security. It's a padlock around a keyboard. And let's think about this in terms of an application architecture. So if we look back maybe 10 or 15 years ago, our applications tended to be structured something like this. You had some load balancer that would do the network ingress. That would hit some firewall. Those might have been the same thing. And then you would hit your secure domain. The application was likely monolithic. So you didn't have microservices. All communication happened with inside the application. And your database and your application lived on the same network. They might have been connected by the same physical, like serial cable connecting these two machines. The load balancer and the firewall were likely hardware appliances, like an F5. And all of this was controlled by one or two people who had a lot of skills in the industry. So the important part to note here is that once we're inside the secure zone, everything was trusted. When we moved to a modern architecture of an application, applications have gotten increasingly more complex. This is due to new programming languages, new requirements, proliferations of things like microservices so we can break apart different things so that different teams can work on different things and accelerate application delivery. But that introduced some complexity. So now we have cloud adoption, where we have some things running on a public cloud, some things running on a private cloud, some things running in both at the same time, and they need to talk to each other. So our modern architectures tend to look something like this. We still have a load balancer, but that load balancer is likely a software-defined load balancer. So not only are we eating some performance, but we're now subject to any vulnerabilities that exist in that language. So that load balancer is written in C, and there's a memory leak, like oops, as opposed to something like an FPGA, which is a hardware-based load balancer. We no longer have a firewall. Instead, we have firewall rules. Again, that's like TLS, we're encrypting the connection, we're encrypting the data over that connection, but we need to encrypt our data at rest as well, so in transit and at rest. At the same time, we need to understand the trade-offs of encrypting that data. There are certain data that should be encrypted, and there's certain data that can live in plain text. If you imagine we have a database of things like email addresses, you might think, oh, I'm going to encrypt those email addresses, because if I get attacked, I'm going to be on the front page of Hacker News, I'm going to be on the Joy Hunts Have I Been Pwn, and that's a very valid way of thinking. And this is where there is no one answer. If I'm a company like MailChimp, where my core business is sending email, email addresses are very important. If I get hacked and I see that there's been a data leak, that's basically the end of my business. On the flip side, if my primary business is cat memes, and I run the top site for cat memes, and I collect email addresses so I can send out a newsletter, if I'm attacked, it's bad. I shouldn't have done that. I should have followed better security practices, but it's not the end of my business. And at the same time, if I encrypt all of my email addresses and my database, I lose the ability to do analytics. I can't search for all email addresses that end in, say, at gmail.com anymore, because they're all encrypted. So I have to make a business decision of should I encrypt this data or should I not encrypt the data? So encryption everywhere isn't the answer. Instead, having a cognitive conversation about whether we should encrypt data everywhere is the answer. And making a business decision and analyzing that risk of whether we should encrypt or not encrypt and what the business trade-offs are for that. The second pillar are these dynamic, time-based, revocable credentials. So in a traditional application development, you might have an app that has to talk to a database. And the way you generally get the credential is you email your DVA team or you file a ticket. They manually provision an account for you. They give it back to you. You put it in the config file for the application. And all of your applications share that same credential, seemingly for the end of time. If you're in a large enterprise, you might rotate them every six months. If you're a startup, you keep them there until you get acquired. This is a challenge. The longer a credential lives, the more likely it will be hacked. So instead of trying to do this whole no one's ever going to infiltrate our systems, we're going to have the best security parameters, we can instead invert the conversation and say, you know what? If someone makes it into our systems, that sucks. We should do better. But our credentials only live for an hour. So at most, an attacker would have to penetrate these three levels, then get in a credential, and use it within an hour. And we can revoke it early. And this is why time-based credentials are very important. I'll say this on the encryption side. And I'll say it here again. Unified APIs and codified best practices. This is arguably the most important concept. And what I'm going to show you in a bit with Vault, which is an open source tool, is we need a central source for secrets. Many organizations out there are writing code in five different programming languages with hundreds of engineers, all with different levels of expertise. We can't expect every Ruby developer, every Java developer, every Go developer, every C developer to reinvent encryption. Instead, we should treat encryption the same way we treat things like databases. They're just a service that is offered. So just like a database is a service that is offered to store data and retrieve data and search data, we should think of security as the same way. There needs to be a service that does security force. So things like encryption as a service, password generation, entropy generation. I shouldn't have to write that in my own language. It would be great if I could just make an API call over, say, SSL with a JSON payload and say, hey, give me 150 bits of random entropy. And I don't want to have to write that in five languages. I would love to just make an API call. And that's kind of the direction that I think security should be going. It's security as a service. If I want to encrypt something, I don't want to have to pick a cypher suite. I don't want to have to know if it should be asymmetric encryption. I just want to have this blob of text. And I want someone else to encrypt it for me with the latest and greatest standards and give me back the encrypted text. And I don't want to have to think about it. I don't want to have to know all of the vulnerabilities that exist. And again, this is the direction I think the security industry is going. And to do that, we need a consistent experience. So it doesn't matter what language you're writing in. It doesn't matter if you're a human or a computer or a service. It doesn't matter if you're an enterprise or a startup. It doesn't matter if you're running on Kubernetes or Mesa's or bare metal. We need a consistent experience. And that's really what Vault tries to be. So Vault is an open source tool written in Go. It runs as a service. And it's designed to be the central repository and central egress and ingress for all credentials within a system. So I'm going to demo it while continuing to talk about it. I have this live demo slide. So I couldn't get my way out of it. So let me just show you how this works. So Vault operates in a client server architecture. Can everyone see this? You're also loud. There we go. All right. So Vault operates in a client server architecture. What I've done here is I'm going to start a Vault server. And I created scripts because I suck at typing. So I'm starting a Vault server. That's exciting. It's running as a service in the background. I'm going to go ahead and open a new tab over here. So I have Vault running. It's running as a service. If I was in production, it would run in high availability mode. But for locally, I just have one instance. And I just make requests against Vault. It acts just like a database where it has data. But we'll see in a little bit that it's a little bit more than that. So just to prove to you that I have a Vault server up and running, there's a Vault server. I just queried for it's status. Vault is conceptually similar to a website. You have to log in to Vault or authenticate to Vault. There's a number of ways you can authenticate. You can authenticate via a username and password. You can authenticate via GitHub token. You can authenticate via LDAP, service accounts, et cetera. The easiest way to think about it is when you log into a website, you put in a username and a password. The username and password is validated against a backend database. And then you get a session token or a session ID. And that's stored in a cookie in your browser. In Vault, the concept of a session ID is called a Vault token. So I'm just going to log into Vault here. And I'm now authenticated to Vault. And I've logged in as the Root account, which is a really bad practice. But this is a demo, so I'm doing it anyway. And this is just going to showcase, it gives me super permissions in the system. So the first component of Vault. And the easiest one to think about with encryption is this what we call the static key value store. The easiest way to think about this is encrypted Redis or encrypted Memcache. I'm going to give Vault some plain text data. Vault is going to encrypt that data in transit with TLS and at rest with AES256 bit encryption. And it's going to store it. When I want it back, I ask Vault for the data back. Vault decrypts it and gives me back the plain text data. So it's going to behave similar to Redis or Memcache, but it's encrypted in transit and at rest. So I do that by writing to anything under secret. So I'm going to create a secret named Wi-Fi. Wow, I can't type. And I'm going to say that the password is, what is the Wi-Fi password? I'm not typing that out. The password is bananas. So I've created this credential. And I can read that credential back out. And I get that my password is bananas. And I can create any number of these secrets. So I might have the bathroom door code. And it might be 1234. And I can actually list these now. And I can see I have two credentials, the bathroom credential and the Wi-Fi credential. And this is nothing special. This is just I gave Vault some data. It encrypted it. It stored it. I want it back. I get it back. That whole process is authenticated, though. So I'm cheating a little bit here. I'm the root account, which is like pseudo in Linux. So I can do anything on the system. But everything involved is actually policy-based. And if you don't have permission, you can't do it. So I could create a policy which lets me read the Wi-Fi password, but not the bathroom code. So work all you want. No breaks for you. Someone got that joke. So this is basic CRUD operation. So the last thing you can do, obviously, is to delete things. So I'll go ahead and delete the bathroom code. And I've now deleted that credential. So basic CRUD operations on a K-value store. It doesn't feel encrypted. How many people feel extra secure using this over something like Redis? Yeah, it doesn't actually feel secure. And I want to talk about that for a second. So the reason for this is that the security industry has kind of preconditioned us to believe that security has to be hard. And part of this is vendors trying to sell their appliances. And part of this is just security was hard for a very long time. Vault is open source. It's been audited, I think, six times now by three different groups, including the NCC group, which is like a leading auditing firm in the security compliance area. It's FIPS 140-2 compliant. It can be PCI compliant if you follow the correct steps for implementation. So it checks all of the boxes, all of the multi-letter acronyms that you're used to with security and compliance, yet we don't feel secure. And that's part of the industry's thing and part of the thing I'm setting out to change is that security doesn't have to be hard. This is a tool that is validated. It is used by government agencies in the world. So it passes all the checks. But this isn't where Vault is cool. I could build this backed by something like Redus or Memcached in an afternoon. So this is just one feature of Vault. Another feature of Vault in where it really shines this notion of dynamic credentials. So here, when we're using the key value store, I give Vault data, Vault encrypts it, and stores it. But what if I have a really large data set? Maybe I have a database with 100 million users in it. And I want to encrypt their passwords or their social security or credit card numbers. I don't want to store that in Vault. That's a lot of data. And Vault isn't a database. It shouldn't be used for replication and sharding. That's a database's responsibility. But I still want to encrypt the data. So what we can use, we can use what's called the transit backup. So instead of Vault encrypting and storing the data, Vault will encrypt and return the data to me. And then it's my responsibility to persist that in my application. So I'll go ahead and show you how that works. Everything in Vault is like a file system. So I'm going to go ahead and enable the transit backend, as we call it. And then I'm going to create an encryption key. So I'm going to go ahead and run this. Set up transit. And now I have this transit backend. And I have an encryption key named MyApp. So what I can do is I can encrypt transit encrypt MyApp. I can encrypt some plain text data. And that data has to be base64 encoded, which I'll explain in a second. And I will say FossAsia. So I've encrypted this. What happened was I sent some plain text data to Vault. Vault encrypted it using a Cypher Suite and returned me this encrypted text. This is also available via the API. Actually, everything I do via the CLI is available via the API. The CLI is just a very thin wrapper around the API. So you could do this at Ruby, or Python, or Java, or with Curl, if you would like. I take this Cypher text, this whole block of text, including the Vault v1. And I store that in my database. When I want the plain text back, I take this entire Cypher text, and I give it back to Vault. But I use the decrypt endpoint slash MyApp. And I give it the Cypher text. And Vault gives me back the plain text. And this is base64 encoded. So if we echo this code, we'll get FossAsia. So the reason that we use base64 encoding is that there's actually no requirement that the data that you're persisting to Vault is representable Zasky characters. PDF, Word document. All of those are things that I should be able to encrypt. But under the hood, this is a JSON payload over HTTP over TLS. And in order to safely transmit those binary bits, I need a transport mechanism. And base64 is one of the most common. So if you are encrypting large blobs of data, base64 encode them, they get sent along with the payload. They come back as a binary safe string, so you can store them in a database and then retrieve them later. So this is a great way to provide encryption as a service. And what's nice is there's a number of different features of this. So it's not just an encryption key. It's actually an encryption key rig. So I can maintain multiple versions. I can upgrade and downgrade my encryption keys to make sure that I'm always using the latest data, and my data is always encrypted with a fresh key. I have third-party processes that can re-encrypt data. I can have my front-end servers with the permission to encrypt data, but not decrypt it. And I can have my back-end servers the ability to decrypt data, but not encrypt it. This will let me have a front-end application that could accept credit card applications. It would encrypt the social security number or the credit card number, put it in the database, but it could never decrypt it. So even if an attacker gained access to my front-end server that had root access on my front-end server, that server is not authorized to decrypt data. So they couldn't actually decrypt it because they have to also compromise vault in that scenario. So it's a multifaceted attack. Similarly, my back-end servers can only decrypt data. If an attacker is able to compromise that service, they can get their credit card numbers, but they can't persist any bad data or any fraudulent data into my system because they can't perform the encryption operation. So this is kind of leading into what involved we call dynamic credentials. Dynamic credentials are things that are created on the fly. So one of the easiest ways to think about dynamic credentials is in terms of databases. Right now, in order to create a database password, you have to run some SQL commands or click and agree. You get back a username and password. You put it in a text file and you share it across all your applications. There's a number of problems with this. Namely, you have one shared credential. So if it's hacked, you have to incur downtime to rotate those credentials. You don't have Providence, which is a one-to-one mapping of an application to its credentials. And it's not good for auditing and logging. You can't do this dissection or diagnosis of a problem. So what we can do in Vault, oops, I ran that before I actually showed you what it was, is Vault can actually connect to a database like Postgres or MySQL or HANA or Oracle. And it can actually dynamically create these credentials. So I'm running a local host here because I did want to rely on the internet. But last night at the meetup, I demoed using this on Cloud SQL, so third-party database service. What I do is I give Vault a root or a privileged credentials to my database, and I give it a series of SQL commands to run to create a user. So here I say create role with login password valid until. And these curly brace things get filled in by Vault. So what will happen is when I make an API request to Vault, Vault will establish a connection to Postgres. It will run this SQL, filling in the things between the curly braces, and give me back a user. So what we've done and what Vault does is it actually provides an HTTP API for programmatically generating SQL users. And this works with Microsoft SQL, Oracle, a lot of mainstream databases out there. You can run any SQL statement. So if you have a stored procedure or if you want to grant privileges on a number of different things, it's just an SQL statement. So I already set that up. And you'll notice here that I've created a role. A role named read-only is like a sim link. So when I want credentials, I ask Vault, hey, give me the credentials that correspond to the SQL statement. And the way I do that is by referencing the role. So I would run something like Vault read. Actually, before I do that, let me prove something to you. So this is my local SQL instance. You can see there's one user in there. That's me. I'm the root user. Now what I'm going to do is I'm going to read from database creds read-only. This is going to generate credentials. So when I hit Enter, Vault actually establishes a connection to my local Postgres cluster, generates a username and password, and it shows it in between those curly braces, executes that SQL, and returns the result to me. So here you'll see we got a username and a password back. This is a real Postgres username and a real Postgres password. And every time I run this command, I'll get a new username and password. So you can see here that they're different. This is useful because all my app has to do is, at boot time, make a request to Vault. If it's authorized and authenticated to do that, it will get back its own unique credential. So that one application has a unique credential to talk to my database. You'll notice that the database credential has a lease duration of 768 hours. It's about a day. Sorry, about a month. It's a long day. It's a day I'm hard on. It's a day on Jupyter. It's not a day on Jupyter. That's about 30 days. So what will happen is after 30 days, this credential will get revoked automatically. So we don't have to worry about rotation and stuff, because we can tell our auditors and our compliance teams, hey, no credential lives longer than 30 days. I could set that to as little as five minutes, if I really wanted to. And then no credential would live longer than five minutes. So to prove this to you, I'll go back here, PSQL. I'll list the users, and you'll see we have two users in here now. So we programmatically, and again, under the hood, this is just an API call. We now have an HTTP API that can generate database users. This is incredibly powerful. And those users have a limited time that they live. They can live for a configurable amount of time anywhere from one second all the way up to five or 10 years. But we're able to time scope these. We can revoke them in advance as well. So right now, I just showed you all my username and password to my database. That probably wasn't a good idea. So what I'm going to do is I'm just going to go ahead and run Vault revoke. And I'm going to revoke all of the database credentials. And just like that, when I go in here, they're all gone. So that's what we call a break-class procedure, which is, oh no, I've been hacked. I need to stop depleting. I'm going to incur downtime, but that's better than losing customer data. I'm going to delete all of my credentials, and I'm going to start from scratch and re-diagnose this problem so that we can find the vulnerability or the infiltration habit. That's how easy it is to revoke these credentials. And you can do it on a subset. You can do it on a full set. You can revoke everything in vaults. Now, that requires a lot of privilege. Not every user can do that. Again, I'm the root user, so I have kind of exponential privilege in the system. But if you do that, you must do any tracing. If you do this, you don't lose tracing because the username and the lease ID are available in an audit log, which is stored separately. Typically, you put that into something like Splunker, some third-party system. So you can still correlate with the logs. How many people here run their own certificate authority? No? You don't like to self-deprecate? So one of the cool features about Vault with these dynamic secrets, and one of the challenges with microservices, especially a lot of them, is you either need some kind of service mesh with something like Istio and Envoy to manage mutual authentication and authorization in the cluster, or you have to manage your own PKI infrastructure. And Vault actually makes that second one easier. So for customers that can't adopt tools like that or aren't ready to make the step to a service mesh, your own internal PKI infrastructure is very helpful. So here what I'm doing is I'm generating a root certificate. I could give Vault my own certificate if I wanted. And then I'm generating a role called my website, where I can actually generate TLS certificates on the fly. So if you're not familiar with PKI infrastructure, don't worry about the curl distribution points and stuff. All you need to know is this is really hard and often involves lots of stack overflow, copying and pasting, and then eventually someone figures it out and puts it in a text file. So what I'm going to do here is I will configure this, so set up PKI. And now what I can do is I can just generate a certificate on the fly. So what I did here is I asked Vault to issue me a certificate for example.com. And that was authorized and authenticated. So I got back the certificate. I get back the public CA chain and the private certificate as well. So there's the issuing CA. And here's my private key. And again, all of this is happening via an API. So there are tools out there that actually do this entirely in memory. So web servers that query Vault for their TLS certificate and only store it in memory. So even if the system is compromised, someone would have to trigger a core dump to get the private key out of these web servers. And again, this is an API under the hood. So you can automate this in any language you'd like. Again, every time I run this command, I'll get a new certificate. And I can revoke the certificates early. So this certificate I think is valid for 30 days. But if all of a sudden I detect an intrusion, I don't trust my application anymore, I can revoke it early, and it can no longer talk within my systems because I'm using mutual TLS, for example. This next one's kind of fun, but it has a real use case. So how many people know what TOTP is? So TOTP is the generic algorithm for one-time passwords or passphrases, multi-factor authentication. Those six or eight-digit codes you get with Google Authenticator or AFI, it's a spec. Vault can actually act as a TOTP per flyer and a TOTP reader. So what's a good use case for this? Remember, everything in Vault is authenticated and logged. And the challenge with multi-factor authentication on something like a AWS root account is that it belongs to a phone or a device. So if you run an operations team, how do you get multiple people access to that MFA code? Do you pass around an RSA secure ID token to people who are on call? Vault is actually a really good solution for that. So you actually store the generation in Vault and then you authorize and authenticate that. And you can write Vault policies against third-party systems. So you can actually say people can only generate the TOTP code if they're on call and link that into something like pager-duty. This means that even if you're in the operations group, you can't actually log into the AWS root account unless you're currently ENOC. So I'll go ahead and show you this. I just have a sample one here. And now what I can do is I can read TOTP code demo and I get back my six-digit code. So you're used to scanning those barcodes. Those barcodes actually correspond to a URL. And you can do that here. After about 30 seconds, this code will rotate and I'll get a new code. So this is the same as like Google Authenticator or Authy or OnePassword doing the cycling. But it's authenticated and audited. If I don't have permission to read this TOTP code, I get permission to die. Vault can also act as a TOTP provider. So if you have an application and you want to add two-factor authentication to your application, you can either implement the entire TOTP spec yourself and hope you get it right, including recovery codes and backups and falling over to SMS. Or you can use something like TOTP as a service. This goes back to kind of Vault's core mantra of security shouldn't be this hard. We're going to give it to you as an API and do the best practices for you. So instead of acting as the thing that generates codes, Vault can actually act as the thing that validates codes, which is a TOTP provider. So I'll show you how that works. Set up TOTP provider. So here I'm generating, I use the generate equals true keyword, but it's the same, what we call a back end or the same generator. So I will run set up TOTP provider and I get back a bunch of text here. This is kind of fun. This first block of text is a barcode. This is a base 64 encoded image of a barcode that you could have your user scan with their mobile application. The second one is the actual OTP off URL, which is encoded in this barcode. So I will attempt to remember the command to do this. So I'm going to copy this to my clipboard. I think it's base 64 dash dash to code, that long string of things, and we'll save that as pure G5. All right, and then we'll open this guy. And it popped up on the other screen, but I promise it's real. Oh, I'm full screen, dang it. There you go. So you can scan this with your app and it'll generate codes, and then you can submit those codes to Vault and Vault will validate them. So again, it's not hard if you follow the TOT spectrum to build this yourself. But the idea is, and Vault's kind of mantra is, if we want teams to do security, and we want teams to do security, well, we have to make it easy. And there's nothing easier than an API that does the best practices for you. So the last thing I want to show you about Vault is it's pluggable nature. So in addition to all of the built-in things, there might be something in Vault that I need to customize. I might run some custom fork of MySQL that doesn't integrate, or I might have some crazy engine that I want to integrate with myself. And I can do that with plugins. And Vault has this really verbose plugin interface with a way to trust cryptographically secure plugins. So I'm going to go ahead and install a plugin here that I wrote. What this plugin does is it allows me to generate random passwords or passphrases. This is really useful if you've ever used something like one password or last pass, where you can generate logins for websites. But I want something that's cryptographically secure, truly random, and I might want to be able to use the Diceware algorithm so that I can generate dictionary or human-readable things. And I want to do things like include symbols or include letters and numbers. This isn't something that's included with Vault. By default, this is the third-party plugin, but I just imported it. So let's say I want a password. I can ask Vault to generate me a password. Gen, in this case, actually maps to a plugin, which I just installed. So Vault generated me a password. I think it's 64 characters in length. It includes letters, numbers, and symbols. This is great. I could use that on a website that doesn't suck. And it would work great. But there are websites out there that suck, right? How many people have ever put a password in, and it's like, no, you can't be more than 12 characters, and all the letters must be five. It happens. And for those cases, you can customize that. So I might want to say the length is 36 characters, because that's an arbitrary limit that someone imposed. And there can be up to 10 digits, but we can't do symbols. So this will give me a 36-character string, which is compliant with the specification. And just like the other credentials we saw, every time I run this command, I'll get a new password. This is cool. Again, this isn't something that's bundled with Vault. This is something that I built in an afternoon to show as a demo. But I also use it for generating passwords. It also generates passphrases. So you might have seen these before. This is part of an algorithm called Diceware. Short and trench monogamy expert polygraph ramble. So this will generate six random words and put them together. This is actually the horse staple battery, something, the XKCD, right? It's actually cryptographically more secure than the other passwords I showed you. But this is way easier to type, especially when it's like Netflix on your Apple TV, and you're scrolling to try to type in all these weird characters. Again, just like the other one, we can customize the number of words. So I can say words equals three. Now I've got three words, and I can customize the separator that exists between them. This one's actually just really fun to play with. Sometimes you get some really weird things. Like the treadmill greedy snooze sandstorm showman pregnant. I like to make up stories about them. If you are into crypto, though, totally unrelated to this talk, I would encourage you to look up the Diceware algorithm. It's really cool, dictionary-based attack. The problem is the computers are really bad at random number generation. So what the Diceware algorithm does is you roll a die, so you generate a number between zero or between one and six. And you do that five or six times. And then that corresponds, like you truncate those digits together, like one, three, four, two, six. That corresponds to the 12,476th entry in a dictionary, which becomes one of those words. It's a really cool, there's a white paper on it, you should look it up. That's that. I'm going to go back to my last two slides. So if you're curious about any of this, but you're like, I need a place to do this, Google Cloud is giving you $3,000 in this check on a slide that you should take a picture of. 10-10, so you should take a picture of this slide. So if you work for a startup that's qualified, you can visit this URL down here or just email a cloud startup to google.com. $3,000 in cloud credit. You can play with Vault all you want, as well as a ton of other features of Google Cloud. There's no reason you shouldn't do it. I will wait for more pictures to be taken. You can also just write down this thing. That's the important part. But this is a pretty slide, so you should take a picture of it. All right, cool. That's all I have for you. Thank you very much. Again, my name is Seth. You can follow me on Twitter. And I'll be here the rest of the conference. Any questions still before Seth? All right, do you want to try or do you want to try? Do you know of anybody using Vault for managing SSH secrets? Yes, so there's a number of what we call secrets engines, which I didn't discuss. There's about 12 of them. SSH is one of them. So Vault can actually act as the thing that sits in the middle. So you install a Vault agent or a Vault helper on the system, and whenever you try to authenticate, your authentication actually goes to Vault. Vault generates a dynamic credential, dynamic SSH key, and locks you in. It's also possible to do that via trusted CA certificates, where you have open SSH trust Vault CA, and then Vault will sign that CA chain. I have a chart that shows how that works. There are a number of people doing it. My problem with that is that if you're truly trying to do security well, no one should access a system after it's online, especially via SSH. So if there's a reason that an operator needs to touch a system like that, that's, in my opinion, a fault of logging, monitoring. We should be able to egress that data through third party systems. There's no reason an operator should have to touch that system. If, in fact, that does happen, though, that system should immediately be taken offline. So if I'm an operator and I need to debug an issue, and I do use something like Vault SSH to access that system, that system should be removed from production immediately upon debugging so that it wasn't tainted, because we can no longer trust it. Just a simple question about the concept you shared around using Vault to issue passwords to the application to connect to the database, and short-lived username and passwords. How do you handle that expiry and rotation of that? Yeah, so the question is, if I have these dynamic credentials, what happens when they expire? That's application dependent, and there's a few strategies. So if you're building a cloud-native application, it likely responds to some type of signal to reload, right? SIG hub or a graceful restart or a hot reloaded configuration. In those situations, you can use what we call sidecar applications that end console and console template that will present the credentials that Vault has as environment variables or a file on disk. And when those credentials change or are about to change, you signal the application to reload as configuration. In the case of a non-cloud-native application, like a Java app that takes four years to boot, typically it's hard. Typically what we see in those scenarios is we adopt Vault for the green-filled applications that can be cloud-native and can adapt to these highly elastic environments. And then for the Java app, we just create a credential that's valid for a year. We still do it in Vault so we can revoke it early. But it's still a manual process until someone can update that application or we can deprecate it. Thanks. I previously used these UB keys. Does Vault have any native support or plug-in support for UB keys? So kind of. So I used to work in HashiCorp. There was, I was in play number four in HashiCorp. So I was there quite a while. Yes and no. So the open source version of Vault does not have support for things like HSMs, which is a derivative of what you're talking about, like a UB key. That's part of the enterprise play. So customers that want hardware-generated entropy can actually connect Vault to an HSM, which could be a UB key or it could be some kind of appliance that generates entropy. And that's a paid product. So it's not available in the open source, but it is a feature that exists. OK. Yeah, we're good. Cool. So that's it. Thanks very much. Thank you. So great. I think we've covered a lot here. Quick announcement that we're going to have a group photo, this year's group photo, today at 12.15. And so if I can just ask everybody to go down to level one and to the exhibition area. So we're just rounding up outside there on the exhibition area. OK, thanks a lot. Thanks.