[00:00] To help keep your sensitive information out of the hands of unauthorized parties, the Secrets Management feature removes passwords, certificates, and encryption keys from the shared gateway configuration. With this layer of data indirection, you can keep access to your application infrastructure more secure. Let's take a look at how to create an internal secret provider on our gateway first. We can go to Platform, select Security, and then choose Secret Providers from the list of options. Next, I'll click the Create Secret Provider button. We can give our secret provider a descriptive name-- Internal_Secret_Provider, since this will use the internal secret type. Once our secret provider is created, it will appear on the main page. If I click on the three dots menu, this shows all the options we have to modify this internal secret provider. We'll focus on Manage Secrets since we need to attach passwords, keys, or other sensitive data to our secret provider in order to use those encrypted values across our gateway.

[01:09] To start this process, I'll select Create Secret. I'd like to create a protected password for this example. Once I have that password in place, I can use my new secret provider and managed secret value to connect the gateway to a PostgreSQL database. I'll give my secret a name: ProtectedPass1. Then I can enter in the secret value that I want. For this example, the value will be encrypted using the default encryption key when I click on Create Secret. Once you save the secret value, it can't be read back. This is a layer of defense to protect the secret. If I wanted to reset that existing secret value later, I could click on the three dots menu for the secret name, choose Edit, and go through the Reset Secret Value workflow to update the information. Since we created our new protected password correctly and don't need to update it, let's use it to help us connect to the PostgreSQL database that I set up earlier.

[02:04] We can go back to the side menu and select connections, then databases, then connections. I'll click on Create Database Connection, choose PostgreSQL from the options, and then hit Next. We'll start in this window with the name of the database connection. I'll just call this PostgreSQL. The username we enter here needs to match the user for the Postgres database that I set up earlier, which is postgres. Since we have an internal secret provider set up, I'm going to include a reference to the Secret by selecting Referenced, choosing our Secret provider, and adding ProtectedPass1 for the secret. With this configuration, the system will know exactly how to dereference the secret and employ it in authenticating with our database. This type of secret is also reusable within the gateway, since all you need is a reference to it in your configuration to use it in other locations or in multiple systems. Any change in the shared secret is reflected immediately to all systems referencing it.

[03:04] This reusability is one of multiple benefits of moving your secrets into secret providers. It avoids secret sprawl by allowing you to centrally manage all your secrets in one place, making tasks such as secret rotation much easier. It also means less repetition. With the new resource collections in 8.3, your development and production environment could have identical settings for a secret reference, such as a database connection password. All that needs to change is the value of the secret in the secret provider between dev and prod. Now, I'll change the connect URL to point to the location of my Ignition PostgreSQL database. This URL uses a combination of the IP address or host name of the database server, the port, the database server is running on and the name of my database. I'll leave the other settings at their defaults and save my changes. After a moment, we can see that there's a valid database connection using our new secret provider secret. This is only one example of how Secrets Management can make your projects more secure.

[04:05] In future videos, we'll look at additional types of secret providers and how to build more robust layers of security within Ignition using the Secrets Management system.