Welcome to this Hashi Corp vault and Red

Hat Open Shift better together demo.

Open Shift is the enterprise standard

for running hybrid applications. But

like Kubernetes, it lacks native

capabilities for secret management,

encryption, and proper access controls,

leaving credentials exposed. Vault is

the enterprise standard to address these

gaps and fully integrates with Open

Shift to centralize and automate life

cycle management of secrets, keys, and

certificates. We'll show you just how

easy it is to automate and secure

secrets for Open Shift applications by

seeing how quick it is to integrate

Vault with the Vault Secrets operator or

VSO and automatically provision secrets

all within Open Shift. We'll start with

static secrets and then dynamic secrets

which automatically rotate. VSO is

recommended for most use cases to bring

Vault secrets natively into Open Shift

as ordinary Kubernetes objects. VSO has

its own Helmchart that you can use to

deploy it without needing to deploy

Vault as well, but we have an even more

seamless recommended approach to start

integrating secrets right away. You can

find VSO directly in Open Shift's

operator hub, which happens to be

officially certified by Red Hat. It

allows for easy installing and automatic

updates. So, if you already have a

cluster built outside of Open Shift, no

need to set up another on here or to set

up a Vault server on the platform. You

can use VSO to integrate your Open Shift

hosted apps with your existing Vault

cluster. Let's go ahead and install it.

So, we now see that VSO is deployed as

an operator with custom resource

definitions or CRDs for the vault

integration. It sits at the cluster

level and can span multiple namespaces.

It allows you to keep secrets

centralized in vault for applications

and users to access and pull only when

needed just in time without constant

pings to stay updated. Let's take a look

at what resources the operator provides.

In this vault connection resource, you

can see the address of our vault

instance defined which is also reused by

the other VSO resources that we'll see.

Let's take a look at how VSO

authenticates to Vault.

We can see here in the spec section that

we're actually using the JAT

authentication method which is actually

our favorite and what we find most

flexible and scalable. But you can also

use other authentication methods such as

Kubernetes, Appal, AWS, GCP depending on

your use case. And it's also specifying

which Open Shift projects are allowed to

use this O method via the allowed name

spaces field. We can also define how VSO

encrypts the O credentials internally

using a transit key via the storage

encryption field. This ensures that the

token used by VSO to connect vault is

always encrypted and never exposed, not

even in the open shift manifest itself.

Now that we know the basics of how VSO

is set up, let's take a look at how it

handles static secrets.

Let's go look at our static app

namespace

and take a look at the YAML. And here is

our vault static secret CRD that's

provided by VSO. It defines how an Open

Shift secret should be synced from a

secret stored in Vault. It specifies the

name of the open shift secret that will

be created using the destination field.

It looks like this static secret is also

set to refresh every two seconds as we

can see in the refresh after field. So

VSO pulls vault to check for updates at

that interval which you can always

change of course. But you can also

configure instant updates by having VSO

subscribe to event notifications from

Vault for instant updates of any

changes. If our application doesn't

support auto refresh of secrets, we can

also tell VSO to trigger a roll out

restart when the secret changes using

the roll out restart targets field,

which we see here and which we'll cover

more of later. In our console here, we

can also view the Open Shift secret

created by VSO. Looking at the secret

details, one thing to note here is the

set of labels attached to these secrets

to help us know more about it and be

able to make it easier for us to audit

them and troubleshoot. This one tells us

that it's been managed by VSO from the

start. As we can see by this managed by

VSO label. This shows us which VSO

resource owns it with the owner ref

field. Let's reveal one of the secrets

values that was synced into Open Shift

directly from vault. Even better, why

don't we take a look at the same value

in action by taking a look at a sample

app that we have open. So here is our

app and this is a simple static website

with some text. But this text isn't

hardcoded. It's actually injected from

Open Shift secrets that were synced in

from Vault using VSO. Let's switch to

bolt this time and update a secret there

to see if the application will reflect

the change automatically.

All right, so this is the key that VSO

is syncing into an open shift secret and

ultimately into the app. Let's create a

new version of the secret in vault and

see what happens.

Now that we updated it, let's go back to

the application, refresh it, and verify

if it went through. Nice. We now see the

value has been updated in the

application automatically thanks to

VSO's ability to sync secrets from vault

into open shift secrets and reflect

those updates in real time without

needing any manual action. Many

organizations actually start off this

way to store static secrets maybe for an

API key that your application needs for

a SAS service or maybe to protect

sensitive values in a config file. So

now you have an idea of how static

secrets work with VSO and you've made it

this far. It's actually just as easy to

begin leveraging dynamic secrets from

here. Let's take a look by switching to

our dynamic app namespace. So if we look

at the resources created for VSO again,

let's filter by this nameace, we see

that we still have the vault connection

and vault off resources. There's also a

vault dynamic secret resource. Let's

open it up. Take a look at the YAML. So

this is how we define a dynamic secret

from vault that should be synced as an

open shift secret. At first glance, this

resource probably looks pretty similar

to the static secrets resource we saw.

But the key difference here for dynamic

secrets is how updates are managed. For

static secrets, if event-based instant

updates aren't enabled, VSO relies on

that refresh after field that we saw and

that set interval to pull Vault for

changes. In contrast, for dynamic

secrets, VSO primarily manages secret

rotation through Vault's lease renewal

mechanism, automatically renewing the

lease before it expires, typically at

2/3 of the TTL value. This ensures

credentials are always valid and rotated

just in time without the need for

polling or event subscriptions. The

refresh after field is still present for

dynamic secrets, but it just serves as a

safety net rather than the main update

trigger. In addition, you can also

configure the renewal percent to tell it

to renew the secret at a specified

percentage of its lifetime rather than a

set time interval in the refresh after.

In this case, we're using a database

type secret, but VSSO also supports

other dynamic secrets like AWS, GCP, and

more. We also see that rollout restarts

are being triggered here as well to

ensure uptime with the latest secrets.

So, if we head back to look at our

secret this time for the dynamic app

projects secret, one thing you may

notice is that unlike the previous

secret we saw, there's no VSO specific

labels here because this one wasn't even

created by VSO, but an existing Open

Shift secret that VSO actually took over

and is now responsible to refresh. A

typical use case where maybe you take

over management of existing secrets that

you already had. This way, you can use

old existing secrets and still benefit

from VSO to enable automatic life cycle

management. for this specific secret

that happens to be for database

credentials. If we look at the username

value, we see at the moment the username

ends in 920. Let's see it in action by

taking a look at a sample app that uses

this dynamic secret to connect to a

database. So I'll open it up in a new

tab. And here we see an app that is

showing us a database username it's

currently using. again coming directly

from that Open Shift secret managed by

VSO. That is showing us that same

database username matching what we just

saw in Open Shift also ending in 920.

Let's keep paying attention to this

username field and see if it gets

refreshed.

All right, it's been a few minutes.

Let's go to the app again and see if

it's been updated. As you can see, the

username has changed. Now it ends in

048. So this shows that the dynamic

secret was successfully rotated and

picked up by the application with

continuous uptime, no manual

intervention and no risk of a long-iving

secret being compromised. So great, you

have secrets syncing from vault and

automatically updating. But how does

this actually affect deployments? And

how does an application actually get it?

Well, when vault secrets are synced into

Open Shift via VSO and surface as native

Open Shift secrets, your applications

that are already designed to consume

them, they continue to work without any

code or deployment changes. That way you

can benefit from Vault's advanced secret

management seamlessly. But not all

applications support hot reloading

secrets. So in these cases, VSO can be

configured as we saw earlier using the

rollout restart targets field to trigger

a rolling restart of apps and

deployments. When a secret is updated, a

rolling restart is triggered, usually

around 2/3 of the TTL value. This

ensures applications are always using

up-to-date secrets without manual

intervention so that you can focus on

building rather than managing secrets,

authentication, and token life cycle. We

can see this here. It looks like a

rollout just got triggered and it's

going through to refresh the

credentials, restarting the pods one by

one while ensuring that one stays up to

keep the app available until ultimately

they've all finished restarting and are

back up with the new secret, ensuring

zero downtime and that running up time

is fully maintained. So this is how you

can get started today by using VSO to

embed Vault right within Red Hat Open

Shift. Unlike trying to daisy chain

different open source projects together,

with Vault you get an enterprise ready

solution. And combined with Open Shift,

you can remove security overhead and

centralize secrets, automate rotation,

simplify audits, and ensure encrypted

secret storage from a single platform

with enterprise scale security, all

without changing how you use Open Shift.

For those with stricter security and

compliance needs that can't touch

Kubernetes-based secrets, stay tuned for

our next video on how you can still use

Vault with Open Shift by mounting

secrets as volume instead.