Welcome to this lesson on OCI vault secrets. In the previous lesson, We have looked at the OCI vault service and specifically the management. The focus of this lesson is secrets and secret management. What are secrets? Secrets are credentials such as passwords, certificates, SSH keys or authentication tokens that you can use with radius OCI Services. Now why would you store the secrets in the OCI vault service? Storing secrets in a vault provides greater security than you might achieve storing them elsewhere, such as a new code or configuration files. You can retrieve secrets from the vault service when you need them, and you can programmatically do that, automate that process to access the sources or other services. That's the main reason why you would use the vault service to store your secrets. As we looked at, using a Secret Manager is a security best practice. As you can see from some of the articles here and code samples, humans tend to take insecure shortcuts. We have all seen hard-coding the secrets in source core, container images, configuration files, etc. Credentials, arguments shared via email, Slack, and shared folders in plain text, as you can see here. Having the ability to store these secrets in a secret Manager is this security best practice. What are some of the questions which come up right, why would you use the service? What happens when an employee leaves? Is it easy to update the secrets they have been using? What happens if a security breach is detected? How fast can we address it? What happens if an external party has access to a server? For how long is it a threat? Can we audit who accessed a particular secret last month, and so on and so forth to different compartments. In case of course I need to access the secret, and so on and so forth. But these are some of the questions which any organization dealing with various kinds of secrets, various services, using those secrets has to answer. Just in a nutshell, first thing to keep in mind, is the secrets are stored with encryption guarantees of a hardware security module that backs the vault. But the secret is created and stored it comes with, the secrets themselves are protected with encryption guarantees of an HSM. We also enforce our dealers in transit and you can always use the fine-grained access control, role-based access control which you achieve through the OCI Identity and Access Management Service. Last but not the least, you get centralized auditing and monitoring on secret usage. You could answer the question we were asking on the previous slide. Who has used the specific secret? Let's say in the last month or so. As we said, you know, this is a central location where you could operate on and manage secret. There's no need to remember where secrets are kept in your code or configuration file. There is a requirement that the data you store as a secret has to be less than 25kB, which is pretty much good for nearly all use cases and the feature is free, it's a service and a feature within the OCI vault service and it's available at no additional cost. As we said at the beginning, it's pretty easy to use. It's pretty easy to automate, scale all the secrets using programmatic methods like the CLI, SDKs or Terraform. There are lots of capabilities around rule management, origins, etc, which we'll see in a quick demo. How would you use this particular capability? Well, let's say you have an application here which wants to access our database. Now, for accessing the database, it needs access to some secrets like the username and password. What you would do then in this case is you will store those secrets in OCI vault here and it says secret service of the OCI vault and first thing you would do is you would call this particular service, get the credentials back in your code. Then you would use those credentials, connect to the database, and then you can retrieve data from the database and several queries. But this is how you create a secret, we'll actually go and build this in a quick demo on the console. As you can see here, this is how you would use the secret. You can see a script here where we are calling the secret capability within the vault service to retrieve some credentials and then let's say we want to connect to a database, we can use those credentials to connect to the database and the advantage here is we don't have to store them in our code or our scripts as it's shown here. Let me quickly jump to the OCI Console and show you a quick demo on secrets. I'm logged into the OCI console and as you can see here, the OCI vault service, I already have a master encryption key created, the name is not for best practice. Here v1, and this is my master encryption key here, this key1. V1 is the vault name and the key is the key1 here that will vault any key. Now what I could do here in this particular vault, I can click on, "Secret" and I can create a secret here. You can see here that I created one earlier, and it's in a pending deletion state. I can click, "Create Secret", and it's pretty easy to create a secret. Let's say I want to create a DBsecret as we looked into the DB credentials on the slides. Right here, I have select a master encryption. I already have a master encryption key available. On the console, I can choose to provide either the plain texts or Base64 encoded value. If I just brought the base text, the console actually does Base64 encoding, so I don't have to do that. Let's say the password, this is my credential. Let's say this is my credential password. If I want to store this, I could store it like this. I can also see my Base64 conversion here. It's rather straightforward. This is my secret, let's say this is my password, and I'm storing this with this particular name. Now there are couple of advanced capabilities here. But the first thing is there are a couple of rules. There is something called a Secret Reuse Rule, and there is something called a Secret Expiry Rule. The Secret Reuse Rule, this type of rule basically prevents the use of secret contents across different versions of a secret. We'll talk about the use case on this. The Secret Expiry Rule basically restricts how long the secret contents of a particular secret version can remain in use. This rule can also block the retrieval of secret contents or a secret, or secret version past that configured expiration date. So you could use these tips as we'll look into these in a couple of minutes. Right here I want to keep it simple, I'm not using any rules. I'll click, "Create Secret", and within a few seconds, my secret will be created here. Now as soon as this gets created, as you can see here, it automatically provides a version number. If I click here, I can click on, "View Secret Contents", and right now it's showing me that decoded Base64 value. If I want to see the plain text, I could see this as my secret, and now I can programmatically call the secret feature within vault and retrieve this information. I don't need to store this in my code, or configuration, or scripts anymore. Now one thing I want to quickly show is how to create a secret version. I can click here and I can say that, create another secret version so I can say, "I am password version2." As I do that, I can set the stage to pending. Now, pending what it does, as you can see here, is it saves that secret but does not put it in active use. By default, new secret versions are set to current, which makes them the current active secrets. If you're not sure, you want to make this current, you could just set it to pending. Right here, I can create another version and you'll see this would take few seconds and my second version will be available here. Right now it's still the first version, the status is shown as current because we have not promoted the second version as the latest current version. We could do that. We could come here and we could say, promote to current. Now, this particular version would become my current version which I can enforce now. If I can see here, I can see that this is my password v2 and this is where the rules come into picture. I could come here and I could create a rule here. I could say, Secret Reuse Rule, and I could enforce this on deleted secret versions. What this would do is let's see if I was using the previous version, the Version 1, and let's say that Version 1 gets compromised, I could just come create another version and then I could make sure that none of the applications use that previous version. I could come and delete that secret version and I would enforce it so nobody could use the previous version or application, when the application makes a call to get the previous version, the service would deny that request. I could also do the expiry rule as we said. You could see how long this particular secret version stays active and you could specify the date here and so on and so forth. I'll just come out of that model. That's pretty much secrets and how you would use them. Remember, this is a security best practice. Instead of embedding these secret credentials in your code or configuration files, you should use leverage capability vault service, and this is available to you for no additional charge.
