Secure Secret Management for DevOps
Key Points
- Secrets are digital credentials that authenticate an entity and define its permissions, enabling secure communication with services.
- In practice, users need credentials to access resources like development repositories, while microservices require configuration data (e.g., database credentials) to interact with each other.
- If secrets are exposed, they can lead to costly data breaches and operational chaos, especially as the number of microservices and applications grows.
- Centralized secret management solutions are essential to isolate, protect, and control access to these credentials, reducing breach risk and simplifying DevOps workflows.
Sections
- Securing Secrets to Prevent Breaches - In this segment, Alex Greer explains what digital “secrets” are, why they’re critical for authenticating entities to services, and how proper secret management in IBM Cloud safeguards data and stabilizes DevOps workflows.
- Centralized Secrets Management Overview - The speaker emphasizes the need to isolate and protect sensitive data via a secrets manager, describing how central storage prevents costly breaches and simplifies developers’ access to credentials, illustrated through a developer’s request for repository access.
- Securing Database Configuration Credentials - The passage outlines using a Secrets Manager integrated with cloud IAM to store DB config credentials for read‑only access to a profile database, warns of catastrophic breaches if these configs are mishandled, and suggests mitigation through proper secret management.
Full Transcript
# Secure Secret Management for DevOps **Source:** [https://www.youtube.com/watch?v=iETENR5MEB8](https://www.youtube.com/watch?v=iETENR5MEB8) **Duration:** 00:09:12 ## Summary - Secrets are digital credentials that authenticate an entity and define its permissions, enabling secure communication with services. - In practice, users need credentials to access resources like development repositories, while microservices require configuration data (e.g., database credentials) to interact with each other. - If secrets are exposed, they can lead to costly data breaches and operational chaos, especially as the number of microservices and applications grows. - Centralized secret management solutions are essential to isolate, protect, and control access to these credentials, reducing breach risk and simplifying DevOps workflows. ## Sections - [00:00:00](https://www.youtube.com/watch?v=iETENR5MEB8&t=0s) **Securing Secrets to Prevent Breaches** - In this segment, Alex Greer explains what digital “secrets” are, why they’re critical for authenticating entities to services, and how proper secret management in IBM Cloud safeguards data and stabilizes DevOps workflows. - [00:03:11](https://www.youtube.com/watch?v=iETENR5MEB8&t=191s) **Centralized Secrets Management Overview** - The speaker emphasizes the need to isolate and protect sensitive data via a secrets manager, describing how central storage prevents costly breaches and simplifies developers’ access to credentials, illustrated through a developer’s request for repository access. - [00:06:37](https://www.youtube.com/watch?v=iETENR5MEB8&t=397s) **Securing Database Configuration Credentials** - The passage outlines using a Secrets Manager integrated with cloud IAM to store DB config credentials for read‑only access to a profile database, warns of catastrophic breaches if these configs are mishandled, and suggests mitigation through proper secret management. ## Full Transcript
How are you making sure that your
secrets are securely stored
so that you can avoid data breaches, as
well as chaos in your DevOps workflows?
Hi, I'm Alex Greer with the IBM Cloud
team, and before I get started
make sure to like and subscribe. Now, what
is a secret?
A secret is a digital credential that is
going to allow entities to communicate
and perform actions on a service. This
discrete piece of information
keeps that access point secure. So, let's
take a look at the
the way in which this paradigm exist. So,
let's start with
an entity here
needs to access some sort of service,
we'll leave it a little ambiguous for
right now, but some sort of service.
So, in order to properly communicate with
the service and be able to take the
action that it needs to to get its job
done
this entity is going to need to
communicate to this service two things.
One - who it is. So, that service can
understand
what or who it's interacting with. Two -
it's going to have to know the set of
permissions that it should grant
in the context of its service.
With these the service can now properly
allow that entity to interact with them.
So, how we enable this is with something
we call
a secret.
So, now with this dynamic establish let's
move into an example with users. So for
users,
we'll say user here's our entity, and
we'll say our service here,
let's just say they it's a developer and
they happen to need read or write access.
So, they're interacting with a
development repo in order to do that.
So, in order to gain that access, again
coming back to the
need we have authorization and
permission, how it's going to communicate
it specifically in this circumstance
is by giving it user credentials.
Now that user can interact with that dev
repo in the way that they need to to get
their job done.
Now looking at a cloud native
application story,
we have a lot of microservices that have
to talk to each other. So,
let's look at that so let's just call it
Service A
needs to interact with a database,
called DB, and grab a piece of specific
information that it needs to
get its job done. So, what it needs
in the form of a secret here
is what we call DB Configs.
Again, this DB Config is going to allow
it to have
the right communication with the service
saying this is who I am
and this is what I came here to
accomplish.
But now that we have our user
credentials and our DB Configs as
example of secrets,
we realize the vulnerability that can be
created here if these were to fall into
the wrong hands.
And this is why it's so important to
establish
a centralized place to manage all these
things as we build out more and more
applications, microservices,
and we have more of these that the problem
becomes more complex.
And if it falls into the wrong hands how
is it protected?
How did we block it from getting to
that point, how is that data isolated?
When we look at the the damage that this
can cause we're looking in the millions
of dollars for example for a data breach.
And in terms of developer operations if
you're not properly managing these,
forget even the case in which a bad
actor hasn't been involved but it can be
confusing for teams to use this.
So, what we need to do is make sure that
we have it again centralized
and properly stored so that we can
leverage these secrets in the right way
and they can properly communicate with
services.
Okay, now let's take a look at the next
layer of of the onion.
in a more complicated example.
Now. let's go back to Jane, the Enterprise
Developer.
Jane, or we'll say E-Dev.,
here needs again to have access to that
development repo that she was referring
to
earlier. Let's just go ahead and call
this maybe
it's GitHub. So, what she needs to be
able to do is have
write access,
and so she's going to give it, she's
going to need to request the information
that's going to give her access to that
right role.
So, that's where a Secrets manager
service comes in
in a perfect complementary fashion.
So a Secrets manager service
can securely store these credentials
along with
other types of secrets in a centralized
way for her to be able to access, or
maybe other services to access like
we'll see in a second.
But what it's done is it's given her the
peace of mind
that her user credentials are
securely stored and now she can worry
about
authenticating and with the service and
getting her job done, because Secrets
manager is going to take care of that
for her.
However, what's really important for a
secrets manager service to do
is interact with the cloud service
providers IAM write, Identity and
Access Management service. So, this
IAM is going to be the source of truth
allowing secrets manager to one,
authenticate
who she is and so that it can pass it
down to GitHhub and secondarily,
also allow for her to get the right set
of roles based on the paradigm that they
have within
their IAM service. So with this we now
understand what it's like for a user
to get the right permission and be able
to access
the tool of their choice or their
service, and be able to do this in the
context of
using a Secrets manager service. But now
let's look what it's like
for a service to interact with another
service,
and potentially where data bridges could
be harmful.
Now let's look at our service to service
example.
So, what we have to start with is that we
have,
let's just call it a lending application,
so lending app,
and this lending app is going to want to
request permissions
to be able to access, again we were
talking about a database earlier,
let's be a little bit more specific, this
database that it needs to access and a
given table within this database
has necessary information to give to its
model in order to be able to make a
judgment on whether or not they want to
provide a consumer a loan.
So, we're going to call this a profile
database, so within here we have
profile DB,
and we know that the set of permissions
that we want to grant are going to be
read permissions for table
A. So again, where are we going to
store the secret that's ultimately going
to give us access to give us access to
authentication
and ultimately to the set of permissions
that we need here. So that's again going
to be the Secrets manager service
provided
and that service needs to talk to cloud
IAM again. So now that we've got this
established,
what type of credential do we have here?
the credential that we have
is called a DB config.
So, let's think about the scenario we
just walked through this DB config
allows this lending application a
service to be able to have
read access or be able to take a
specific set of information from a given
table
within a database that has some IP data
and some other highly sensitive
information in it.
So in a scenario in which these DB configs
are not stored properly,
or the service that they stored in is
compromised,
what we ultimately get is a pretty
catastrophic scenario for the provider
because the provider of the service of
this lending application then has to go
and tell its customer
that a bad actor was able to take
advantage of access that it got
wrongfully to its DB config, and that
DB config ultimately
allowed that bad actor to steal their
data and do whatever they wanted with it
against that customer. So, what we can do
to mitigate it again,
is store it in a safe location where bad
actors do not have access and you have
the level of data isolation
that you're comfortable with as an
enterprise. So, that's where we have
Secrets manager services.
So again, Secrets manager services
help to ensure the secure storage of
secrets
so that you don't have to worry about
data breaches from lost credentials or
from other types of secrets,
and ultimately it makes it a little more
efficient for the management
of your your secrets while you're going
through your DeVops operations.
Thank you. If you have questions please
drop us a line below.
If you want to see more videos like this
in the future please like and subscribe.
And don't forget,
you can grow your skills and earn a
badge with IBM CloudLabs, which are free
browser-based interactive Kubernetes
labs.