Loading video player...
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.
See how the Vault Secrets Operator (VSO) automates secure secrets in Red Hat OpenShift, both static and dynamic rotating credentials, natively in the OpenShift UI and without changing your workflows. Try it now → https://developer.hashicorp.com/vault/docs/deploy/kubernetes/vso/openshift?utm_source=youtube&utm_medium=organic_video&utm_campaign=utm_vault-openshift-demo-1&utm_content=&utm_offer=video In this demo, we show how HashiCorp Vault and Red Hat OpenShift work better together to solve one of Kubernetes’ biggest challenges: secure and scalable secrets management. You’ll see how the Vault Secrets Operator (VSO), a Red Hat officially certified operator and the recommended Vault integration for OpenShift, makes it easy to centralize, encrypt, rotate, and inject secrets directly into OpenShift as native Kubernetes objects, without changing how you use the platform and your existing workflows. This way you and your teams can do what they do best, with security being automated. We walk through real-world use cases entirely in the OpenShift UI, including: - Installing Vault Secrets Operator from OpenShift’s OperatorHub - Securely authenticating OpenShift to Vault using JWT auth - Syncing static secrets from Vault into OpenShift and updating apps in real time - Managing dynamic secrets with automatic rotation - Taking over existing OpenShift secrets and adding lifecycle management - Handling applications that don’t support hot-reloading using rolling restarts - Maintaining zero downtime while secrets rotate automatically Unlike stitching together multiple open source tools, Vault provides an enterprise-grade solution for secrets, keys, and certificates that’s fully integrated with OpenShift and backed by an official Red Hat partnership. Whether you’re securing application credentials, CI/CD pipelines, or hybrid cloud workloads, this demo shows how VSO helps decouple security from the development lifecycle while improving both security posture and operational efficiency. 0:00 - Intro 0:49 - VSO Installation and Configuration 2:22 - Static Secrets 4:47 - Dynamic Secrets 7:38 - Automated Rolling Restarts 8:38 - Conclusion Product: HashiCorp Vault, Red Hat OpenShift; fullname: Ferris Arley #VaultSecretsOperator #OpenShift #HashiCorpVault Subscribe to our YouTube Channel → https://www.youtube.com/c/HashiCorp?sub_confirmation=1 For hands-on interactive labs, visit HashiCorp Developer → https://developer.hashicorp.com/ HashiCorp, an IBM company, helps organizations automate hybrid cloud environments with Infrastructure and Security Lifecycle Management. HashiCorp offers The Infrastructure Cloud on the HashiCorp Cloud Platform (HCP) for managed cloud services, as well as self-hosted enterprise offerings and community source-available products. For more information, visit hashicorp.com. For more information → https://hashicorp.com LinkedIn → https://linkedin.com/company/hashicorp X → https://x.com/HashiCorp Facebook → https://facebook.com/HashiCorp