Okay, so now Alex, we present his work with Hopembaoad Itham Agitla, sorry.
Thank you.
Hello, everyone.
I'm Alex Sheel, I'm a staff back in Nigeria at Gillab.
I'm chair of the OpenBow Technical Steering Committee.
I'm here to talk about OpenBow and it's used to Jack Gillab.
First of all, you're probably wondering, what is OpenBow?
OpenBow is a fork of hash corp vault,
remaining under the original Mozilla Public License with Open Governance,
under the Linux Foundation's LFedge Sub-Project.
It is an immense sequence manager supporting poor categories of features.
We have static secrets, provision by users,
security and security stored on KB Mount.
We have dynamic secrets, automatically generated on demand to integrate things like databases,
or cloud identity credentials.
We have encryption services, like a PI engine or SSH certificates,
creation and also KMS like encryption as a service functionality.
And lastly, we have sync management and visibility over all of these secrets,
integrations with things like Kubernetes, external secret operator,
a certain manager, a custom templating engine,
to handle last mile delivery of secrets.
On top of this, all is other logs and tracking access to the system.
Really, this is the equivalent to applications,
what one password is for humans.
It is a password manager for developers, for applications,
to connect with third-party systems.
OpenBow is a PI driven and highly flexible.
It supports different authentication engines from OIDC and Kubernetes,
to LDAPing Kubernetes that we've been talking about a lot.
And we also on the back end then support creating or storing many types of identities.
And it really functions as an identity brokerage.
You take an important potential.
You exchange it for any number of credentials on the back end.
And the goal here is to trade off a little bit of operational risk.
You have to run another complex service.
To lessen the security risk of compromise.
You can enforce a healthy secrets posture in your organization.
You enforce them to use a secret manager.
Audit, rotation, ensure that it occurs.
Handle revocation of these credentials.
And limit your organization's exposure in the event of a compromise
and be able to track that across your org.
While a complete history of OpenBow would take a little bit,
there's a few important events that I want to highlight.
Hashtagrop started the project.
The name did vault back in April of 2015,
so there's been nearly a decade of work in the community.
In August of 2023, Hashtagrop announced that they'd be releasing
their products into the Moray to be open source.
No, no, it's the eye.
Business source license, violating freedom zero to run it.
In any way you'd like.
The triggered and early fork of terraform.
One of the other projects that they've released into open tofu.
Our sister project also under the likes Foundation.
But this fork of vault was started by IBM Software.
It came a little later in November of that year.
We kept with the naming trend.
Unlike open tofu, though, which was made up of many different
member companies all working together on terraform at the time.
OpenBow was more of a grassroots community led.
We've done eight releases, two major releases, six security patches.
Chips up a bug fixes, core improvements, put together
technical steering committee, governance documents, all of that
good stuff.
In July, my company got joined full-time.
And she's voting status in the GSC in October.
This last year.
And so, to my knowledge, and incredibly fortunate to be one of
few people employed to work on open mail full-time.
One of the things you might be asking is, okay, it's another fork of
another hash core product.
What's different?
OpenBow remains in the spirit of the original project, but we've made a few
changes to make it easier to maintain and contribute.
We started with a reduced base, removing many components that
was hard to support as an open source group with no formal funding.
Anything proprietary, anything cloud.
We simply did not have funds to deal with or time to debug.
That also made some hard choices around storage backends.
We only support raft and postgres support out of the original
myriad of different storage backends.
But we hope to change as we get more time and funding, and we
introduce especially to the cloud, all-things, and credentials.
But using that space, we've made some core technological
improvements to the storage subsystem, adding
paginated lists, and transactions which in turn
allowed us to improve scalability.
These were justly made possible by removing all of the
storage backends but raft and playing with that core until we
got the things we needed.
We hope to add an external storage API in the future for people who
want to run on these third-party data centers, but without
restricting us to maintain compatibility for all of them
upstream.
And of course, different from Hesh Corp.
We set up an open organization with a clear
contribution process, and clear what project leadership
guidelines, so that anyone can come to our community,
know how to contribute, know how to get their patches landed,
right in RFC, change of the design, change the architecture,
but still under the original Mozilla license.
My personal vision for this is something like Kubernetes.
Large companies, small companies, medium-sized companies
can come to contribute patches.
They can find a niche.
They're space for people and careers to grow in this space.
And so I think it's cool.
You might be wondering, why get lab?
What is get lab using open mail for?
Get lab is a more complete DevSecOps platform than just
a simple get-forge.
Our customers really see a problem managing secrets in their
CICD pipelines.
They have two options that we support now at get-let.
You can use variables.
They're encrypted.
You can mark them as masked, but they have few controls
for their skills of access.
You can't easily limit certain secrets.
Limits certain variables to certain individuals.
And there's a scale problem.
Some customers have thousands upon thousands of variables,
most of which aren't secrets.
And the ideal behavior between these two,
between secrets and variables,
differ in terms of management operation,
and over them.
So no one solution would really work for both
while they're still lumped together.
Instead, many customers turn to our third party
integrations.
GCP has to go up both.
But the user experience isn't quite there.
One typically has to work across several teams to enable
ID, OID, authentication.
So pipelines can authenticate into the secrets managers.
They have to figure out the logistics of storing
in their particular secret manager.
And in all of this, get-let plays a very minor role.
What we do is provision ID token,
touch a couple of secrets from a runner.
And so we lack visibility into the hierarchy
and the architecture that the customer has set up
within their secrets manager.
And so can't assist.
So there's no easy to use dashboard that you can just go to
to configure your secrets within your project.
And you can't really get there from where we are now.
And there's also this political problem of developers
having to work across all these teams to figure out who owns
each portion.
And we hope to do something about that.
So in May 2023, get-let started on a design building
that's the secret manager from scratch.
And in May, unless you're a colleague,
Justin, wrote a blog post talking about how we're going to use OpenBow
to solve this problem instead.
OpenBow is a great choice for GitLab,
because we are a support hash portfolio.
For premium development, tier customers,
the pipeline runners supports native integration
to fetch the secrets automatically and inject them
into the environment of the runner.
In the CI jump, and they have a little nicer syntax
around that versus manual CLAT calls to fault.
But being the mature secrets manager's solution already,
OpenBow brings several useful properties.
There's already been deployed at scale by various people.
It has historically undergone audits and
certification useful for our enterprise customers.
And there's a self-contained service that we can isolate
from the rest of our environment and run as a trusted entity.
And so what we'd like to do is provide a single dashboard,
which lets us aggregate information about secrets within this project.
And correlate them with the audit logs that OpenBow
and GitLab produce.
Handle that management and that logistical organization
secrets on behalf of the user.
At its core, our architecture is just like it was before.
If somebody was running, hash core bolts,
but we moved that into GitLab.
It remains a separate service that exists within our architecture.
Eventually customers will be able to bring their own cameras
provider to encrypt their own data.
What is new are the interactions typically driven by a user
via their browser to our Rails service,
to initiate these secret management operations?
Did you see via the API, which is embedded in our UI,
to enforce initial authentication and access openBow
in a very privileged way to manage policies and other things?
Eventually we'll add a per user JWT,
so that users will directly write their secrets
and openBow and Rails will never see it.
But we get a very clean trust separation here
between three key entities between the pipelines,
which shocked to openBow directly to fetch secrets
between Rails, which talks to openBow in a more privileged manner,
but which never reads secrets.
Obviously, openBow is self-contained in the sorts of truth
for all authorization to secrets and the actual storage of the secret.
With Postgres support, landing in openBow officially,
we'll be using that as our backend database.
We hope to make improvements to it.
Hopefully, allow us to do self-managed GitLab deployments.
As well as GitLab dedicated.com support.
The key data rating openedBow is to be opinionated
about your storage of secrets within it.
We were just discussing this outside,
but GitLab is out there at a booth right next to all the other databases
and we're kind of wondering why there.
Because if you think about it, openBow is really
a key value database.
It's an API structure with rewrite and delete capabilities
on certain mouths.
That's a thin interface.
Sometimes to a KB store, or dynamically create
credentials on the fly.
OpenBow authenticates.
User authenticates to openBow using some engine.
OpenBow is used to token that token gets some mapping
to ACL policies, and there's no concept of this long-term identity
or ownership of a secret.
It's a relatively API driven flat design.
The core of the design then is to integrate with openBow
to provide multi-tenancy and complete isolation
of secrets via a trusted manager, which is GitLab Rails.
And it's a familiar architecture to many of our customers
who won Hashka vault clusters of their own.
Each tenant, usually in owner of a repository,
or organization, has the separate path area within openBow.
Within the space they have an authentication engine,
a JBUT off for authorizing pipelines access to secrets.
Each project has its own KBB2 secrets engine,
which stores the actual secrets.
And it's stored in a structure format with custom metadata
so that we know the scope of access
and contextual information like descriptions and dates.
Rails can, of course, read this metadata
and provision ACL policies and JBUT off-rolls
for all scopes when things change.
When we add namespace support to openBow upstream,
we'll provision each of these tenants in separate namespaces,
and long-term we wish to add support
for per name space, seal mechanisms,
and encrypted key rings to provide gated data isolation,
especially on GitLab.com.
Within the core management space on the right,
there's another authorization engine,
the Rails, state of the TELF,
used for this management interface.
This gives Rails access to its own policy,
but then also to set project and tenant policies
within that ACL role collection.
Authentication occurs by on more of a property based model.
We already have IDC ID tokens issued by GitLab
to pipeline workers that have metadata
like the owner of the repository,
branch the environment,
and so we translate these tokens
via the JBUT off-roll into concrete ACL policies
based upon these properties.
The policies then contain the list of secrets
that that environment that scope that property has access to.
This lets us use OpenBall as a single source of truth.
For all secret management operations,
there are no entries in the GitLab Rails database
at all for secrets within OpenBall.
And Rails is simply a management engine
and a trusted token issuer,
and does not store much other data.
From a developer's perspective,
this looks like the following.
You're going to use the UI to create a new secret.
It's going to be a nice interface.
You're going to enter your name and your value over your secret.
All that good stuff.
You set some restrictions around the environment
and scope.
And then you'll save that.
Then in your GitLab CICD pipeline configuration
you'll reference the GitLab secret manager
and the name that you set up on the left
and GitLab will handle all of the rest.
The management of the access in the deployment.
So, a GitLab we're really excited about working on OpenBall.
If you are too, we welcome all contributors of any sort.
We have our community calls, went online.
We have a roadmap vision for where we want to take the project
as a community.
We have various working groups working on
adding support for things like game spaces,
pieces, 11HSM modules,
and horizontal scalability.
If you like anything open-door related,
please also share it on social media
with colleagues, just great to build the community.
If you're a customer of GitLab and you're interested in
what we're doing, ask your account team about joining
the beta program for our secret manager.
I'm happy to take questions now, Lair.
You can always find me at the GitLab booth
afterwards, or we have stickers, or if you want to
selfie with our little mascot, Bob Allen.
We have a posh version of that outside, so.
Thank you.
APPLAUSE
So, the first question comes from the Matrix Room.
Will GitLab support masking secrets coming from OpenBall?
Masking secrets? Yes.
Our existing Vault Enterprise integration,
supports masking secrets from third-party
secret managers, so that will continue for our
native secret manager offering.
Open them.
Any other question?
On the which subscription tier will this be in
GitLab, so will it be in the open-source version?
That's a little up in the air right now.
I suspect it will be at least premium, but that is
still being worked on and decided.
Thank you.
For the time being, but if we get a lot of interest,
I don't know.
The question was, was the question running
off in the micro?
Go repeat.
Hello.
When is general availability planned?
General availability?
Are there any plans at all yet?
Yes.
Later this year is our rough time line.
The question was, is there a timeline for general availability of this
at GitLab later this year?
Hopefully.
Not yet concrete.
That's all.
Very good.