WEBVTT

00:00.000 --> 00:13.000
Okay, so now Alex, we present his work with Hopembaoad Itham Agitla, sorry.

00:13.000 --> 00:14.000
Thank you.

00:14.000 --> 00:18.000
Hello, everyone.

00:18.000 --> 00:21.000
I'm Alex Sheel, I'm a staff back in Nigeria at Gillab.

00:21.000 --> 00:25.000
I'm chair of the OpenBow Technical Steering Committee.

00:25.000 --> 00:29.000
I'm here to talk about OpenBow and it's used to Jack Gillab.

00:30.000 --> 00:34.000
First of all, you're probably wondering, what is OpenBow?

00:34.000 --> 00:38.000
OpenBow is a fork of hash corp vault,

00:38.000 --> 00:42.000
remaining under the original Mozilla Public License with Open Governance,

00:42.000 --> 00:46.000
under the Linux Foundation's LFedge Sub-Project.

00:46.000 --> 00:51.000
It is an immense sequence manager supporting poor categories of features.

00:51.000 --> 00:54.000
We have static secrets, provision by users,

00:54.000 --> 00:58.000
security and security stored on KB Mount.

00:58.000 --> 01:03.000
We have dynamic secrets, automatically generated on demand to integrate things like databases,

01:03.000 --> 01:06.000
or cloud identity credentials.

01:06.000 --> 01:12.000
We have encryption services, like a PI engine or SSH certificates,

01:12.000 --> 01:16.000
creation and also KMS like encryption as a service functionality.

01:16.000 --> 01:21.000
And lastly, we have sync management and visibility over all of these secrets,

01:21.000 --> 01:25.000
integrations with things like Kubernetes, external secret operator,

01:25.000 --> 01:28.000
a certain manager, a custom templating engine,

01:28.000 --> 01:31.000
to handle last mile delivery of secrets.

01:31.000 --> 01:36.000
On top of this, all is other logs and tracking access to the system.

01:36.000 --> 01:40.000
Really, this is the equivalent to applications,

01:40.000 --> 01:42.000
what one password is for humans.

01:42.000 --> 01:47.000
It is a password manager for developers, for applications,

01:47.000 --> 01:50.000
to connect with third-party systems.

01:50.000 --> 01:53.000
OpenBow is a PI driven and highly flexible.

01:53.000 --> 01:57.000
It supports different authentication engines from OIDC and Kubernetes,

01:57.000 --> 02:02.000
to LDAPing Kubernetes that we've been talking about a lot.

02:02.000 --> 02:08.000
And we also on the back end then support creating or storing many types of identities.

02:08.000 --> 02:11.000
And it really functions as an identity brokerage.

02:11.000 --> 02:13.000
You take an important potential.

02:13.000 --> 02:18.000
You exchange it for any number of credentials on the back end.

02:19.000 --> 02:24.000
And the goal here is to trade off a little bit of operational risk.

02:24.000 --> 02:28.000
You have to run another complex service.

02:28.000 --> 02:31.000
To lessen the security risk of compromise.

02:31.000 --> 02:35.000
You can enforce a healthy secrets posture in your organization.

02:35.000 --> 02:37.000
You enforce them to use a secret manager.

02:37.000 --> 02:40.000
Audit, rotation, ensure that it occurs.

02:40.000 --> 02:43.000
Handle revocation of these credentials.

02:43.000 --> 02:48.000
And limit your organization's exposure in the event of a compromise

02:48.000 --> 02:53.000
and be able to track that across your org.

02:53.000 --> 02:58.000
While a complete history of OpenBow would take a little bit,

02:58.000 --> 03:01.000
there's a few important events that I want to highlight.

03:01.000 --> 03:04.000
Hashtagrop started the project.

03:04.000 --> 03:07.000
The name did vault back in April of 2015,

03:07.000 --> 03:11.000
so there's been nearly a decade of work in the community.

03:11.000 --> 03:15.000
In August of 2023, Hashtagrop announced that they'd be releasing

03:15.000 --> 03:19.000
their products into the Moray to be open source.

03:19.000 --> 03:20.000
No, no, it's the eye.

03:20.000 --> 03:24.000
Business source license, violating freedom zero to run it.

03:24.000 --> 03:26.000
In any way you'd like.

03:26.000 --> 03:28.000
The triggered and early fork of terraform.

03:28.000 --> 03:32.000
One of the other projects that they've released into open tofu.

03:32.000 --> 03:37.000
Our sister project also under the likes Foundation.

03:38.000 --> 03:41.000
But this fork of vault was started by IBM Software.

03:41.000 --> 03:44.000
It came a little later in November of that year.

03:44.000 --> 03:47.000
We kept with the naming trend.

03:47.000 --> 03:50.000
Unlike open tofu, though, which was made up of many different

03:50.000 --> 03:54.000
member companies all working together on terraform at the time.

03:54.000 --> 03:58.000
OpenBow was more of a grassroots community led.

03:58.000 --> 04:04.000
We've done eight releases, two major releases, six security patches.

04:05.000 --> 04:08.000
Chips up a bug fixes, core improvements, put together

04:08.000 --> 04:12.000
technical steering committee, governance documents, all of that

04:12.000 --> 04:14.000
good stuff.

04:14.000 --> 04:19.000
In July, my company got joined full-time.

04:19.000 --> 04:22.000
And she's voting status in the GSC in October.

04:22.000 --> 04:23.000
This last year.

04:23.000 --> 04:27.000
And so, to my knowledge, and incredibly fortunate to be one of

04:27.000 --> 04:33.000
few people employed to work on open mail full-time.

04:33.000 --> 04:37.000
One of the things you might be asking is, okay, it's another fork of

04:37.000 --> 04:39.000
another hash core product.

04:39.000 --> 04:41.000
What's different?

04:41.000 --> 04:45.000
OpenBow remains in the spirit of the original project, but we've made a few

04:45.000 --> 04:48.000
changes to make it easier to maintain and contribute.

04:48.000 --> 04:53.000
We started with a reduced base, removing many components that

04:53.000 --> 04:57.000
was hard to support as an open source group with no formal funding.

04:57.000 --> 05:00.000
Anything proprietary, anything cloud.

05:00.000 --> 05:06.000
We simply did not have funds to deal with or time to debug.

05:06.000 --> 05:09.000
That also made some hard choices around storage backends.

05:09.000 --> 05:14.000
We only support raft and postgres support out of the original

05:14.000 --> 05:16.000
myriad of different storage backends.

05:16.000 --> 05:22.000
But we hope to change as we get more time and funding, and we

05:22.000 --> 05:25.000
introduce especially to the cloud, all-things, and credentials.

05:25.000 --> 05:28.000
But using that space, we've made some core technological

05:29.000 --> 05:32.000
improvements to the storage subsystem, adding

05:32.000 --> 05:35.000
paginated lists, and transactions which in turn

05:35.000 --> 05:38.000
allowed us to improve scalability.

05:38.000 --> 05:40.000
These were justly made possible by removing all of the

05:40.000 --> 05:44.000
storage backends but raft and playing with that core until we

05:44.000 --> 05:46.000
got the things we needed.

05:46.000 --> 05:50.000
We hope to add an external storage API in the future for people who

05:50.000 --> 05:53.000
want to run on these third-party data centers, but without

05:53.000 --> 05:56.000
restricting us to maintain compatibility for all of them

05:56.000 --> 05:58.000
upstream.

05:58.000 --> 06:01.000
And of course, different from Hesh Corp.

06:01.000 --> 06:03.000
We set up an open organization with a clear

06:03.000 --> 06:07.000
contribution process, and clear what project leadership

06:07.000 --> 06:12.000
guidelines, so that anyone can come to our community,

06:12.000 --> 06:15.000
know how to contribute, know how to get their patches landed,

06:15.000 --> 06:19.000
right in RFC, change of the design, change the architecture,

06:19.000 --> 06:24.000
but still under the original Mozilla license.

06:24.000 --> 06:30.000
My personal vision for this is something like Kubernetes.

06:30.000 --> 06:34.000
Large companies, small companies, medium-sized companies

06:34.000 --> 06:36.000
can come to contribute patches.

06:36.000 --> 06:38.000
They can find a niche.

06:38.000 --> 06:44.000
They're space for people and careers to grow in this space.

06:44.000 --> 06:48.000
And so I think it's cool.

06:48.000 --> 06:51.000
You might be wondering, why get lab?

06:51.000 --> 06:55.000
What is get lab using open mail for?

06:55.000 --> 06:59.000
Get lab is a more complete DevSecOps platform than just

06:59.000 --> 07:01.000
a simple get-forge.

07:01.000 --> 07:06.000
Our customers really see a problem managing secrets in their

07:06.000 --> 07:09.000
CICD pipelines.

07:09.000 --> 07:12.000
They have two options that we support now at get-let.

07:12.000 --> 07:14.000
You can use variables.

07:14.000 --> 07:15.000
They're encrypted.

07:15.000 --> 07:19.000
You can mark them as masked, but they have few controls

07:19.000 --> 07:20.000
for their skills of access.

07:20.000 --> 07:23.000
You can't easily limit certain secrets.

07:23.000 --> 07:27.000
Limits certain variables to certain individuals.

07:27.000 --> 07:30.000
And there's a scale problem.

07:30.000 --> 07:33.000
Some customers have thousands upon thousands of variables,

07:33.000 --> 07:36.000
most of which aren't secrets.

07:36.000 --> 07:39.000
And the ideal behavior between these two,

07:39.000 --> 07:42.000
between secrets and variables,

07:42.000 --> 07:44.000
differ in terms of management operation,

07:44.000 --> 07:45.000
and over them.

07:45.000 --> 07:48.000
So no one solution would really work for both

07:48.000 --> 07:52.000
while they're still lumped together.

07:52.000 --> 07:55.000
Instead, many customers turn to our third party

07:55.000 --> 07:57.000
integrations.

07:57.000 --> 07:59.000
GCP has to go up both.

07:59.000 --> 08:03.000
But the user experience isn't quite there.

08:03.000 --> 08:07.000
One typically has to work across several teams to enable

08:07.000 --> 08:10.000
ID, OID, authentication.

08:10.000 --> 08:13.000
So pipelines can authenticate into the secrets managers.

08:13.000 --> 08:17.000
They have to figure out the logistics of storing

08:17.000 --> 08:20.000
in their particular secret manager.

08:20.000 --> 08:23.000
And in all of this, get-let plays a very minor role.

08:23.000 --> 08:26.000
What we do is provision ID token,

08:26.000 --> 08:29.000
touch a couple of secrets from a runner.

08:29.000 --> 08:32.000
And so we lack visibility into the hierarchy

08:32.000 --> 08:35.000
and the architecture that the customer has set up

08:35.000 --> 08:37.000
within their secrets manager.

08:37.000 --> 08:40.000
And so can't assist.

08:40.000 --> 08:45.000
So there's no easy to use dashboard that you can just go to

08:45.000 --> 08:48.000
to configure your secrets within your project.

08:48.000 --> 08:53.000
And you can't really get there from where we are now.

08:53.000 --> 08:56.000
And there's also this political problem of developers

08:56.000 --> 09:00.000
having to work across all these teams to figure out who owns

09:00.000 --> 09:01.000
each portion.

09:01.000 --> 09:03.000
And we hope to do something about that.

09:03.000 --> 09:07.000
So in May 2023, get-let started on a design building

09:07.000 --> 09:09.000
that's the secret manager from scratch.

09:09.000 --> 09:12.000
And in May, unless you're a colleague,

09:12.000 --> 09:16.000
Justin, wrote a blog post talking about how we're going to use OpenBow

09:16.000 --> 09:20.000
to solve this problem instead.

09:20.000 --> 09:22.000
OpenBow is a great choice for GitLab,

09:22.000 --> 09:25.000
because we are a support hash portfolio.

09:25.000 --> 09:27.000
For premium development, tier customers,

09:27.000 --> 09:30.000
the pipeline runners supports native integration

09:30.000 --> 09:33.000
to fetch the secrets automatically and inject them

09:33.000 --> 09:36.000
into the environment of the runner.

09:36.000 --> 09:43.000
In the CI jump, and they have a little nicer syntax

09:43.000 --> 09:49.000
around that versus manual CLAT calls to fault.

09:49.000 --> 09:52.000
But being the mature secrets manager's solution already,

09:52.000 --> 09:54.000
OpenBow brings several useful properties.

09:54.000 --> 09:58.000
There's already been deployed at scale by various people.

09:58.000 --> 10:01.000
It has historically undergone audits and

10:01.000 --> 10:04.000
certification useful for our enterprise customers.

10:04.000 --> 10:07.000
And there's a self-contained service that we can isolate

10:07.000 --> 10:12.000
from the rest of our environment and run as a trusted entity.

10:12.000 --> 10:15.000
And so what we'd like to do is provide a single dashboard,

10:15.000 --> 10:20.000
which lets us aggregate information about secrets within this project.

10:20.000 --> 10:23.000
And correlate them with the audit logs that OpenBow

10:23.000 --> 10:25.000
and GitLab produce.

10:25.000 --> 10:29.000
Handle that management and that logistical organization

10:29.000 --> 10:34.000
secrets on behalf of the user.

10:34.000 --> 10:37.000
At its core, our architecture is just like it was before.

10:37.000 --> 10:39.000
If somebody was running, hash core bolts,

10:39.000 --> 10:44.000
but we moved that into GitLab.

10:44.000 --> 10:49.000
It remains a separate service that exists within our architecture.

10:49.000 --> 10:53.000
Eventually customers will be able to bring their own cameras

10:53.000 --> 10:56.000
provider to encrypt their own data.

10:56.000 --> 11:00.000
What is new are the interactions typically driven by a user

11:00.000 --> 11:04.000
via their browser to our Rails service,

11:04.000 --> 11:09.000
to initiate these secret management operations?

11:09.000 --> 11:14.000
Did you see via the API, which is embedded in our UI,

11:14.000 --> 11:19.000
to enforce initial authentication and access openBow

11:19.000 --> 11:23.000
in a very privileged way to manage policies and other things?

11:24.000 --> 11:28.000
Eventually we'll add a per user JWT,

11:28.000 --> 11:31.000
so that users will directly write their secrets

11:31.000 --> 11:35.000
and openBow and Rails will never see it.

11:35.000 --> 11:39.000
But we get a very clean trust separation here

11:39.000 --> 11:43.000
between three key entities between the pipelines,

11:43.000 --> 11:45.000
which shocked to openBow directly to fetch secrets

11:45.000 --> 11:51.000
between Rails, which talks to openBow in a more privileged manner,

11:51.000 --> 11:54.000
but which never reads secrets.

11:54.000 --> 11:57.000
Obviously, openBow is self-contained in the sorts of truth

11:57.000 --> 12:03.000
for all authorization to secrets and the actual storage of the secret.

12:03.000 --> 12:07.000
With Postgres support, landing in openBow officially,

12:07.000 --> 12:10.000
we'll be using that as our backend database.

12:10.000 --> 12:13.000
We hope to make improvements to it.

12:13.000 --> 12:18.000
Hopefully, allow us to do self-managed GitLab deployments.

12:18.000 --> 12:23.000
As well as GitLab dedicated.com support.

12:23.000 --> 12:27.000
The key data rating openedBow is to be opinionated

12:27.000 --> 12:32.000
about your storage of secrets within it.

12:32.000 --> 12:35.000
We were just discussing this outside,

12:35.000 --> 12:39.000
but GitLab is out there at a booth right next to all the other databases

12:39.000 --> 12:42.000
and we're kind of wondering why there.

12:42.000 --> 12:45.000
Because if you think about it, openBow is really

12:45.000 --> 12:47.000
a key value database.

12:47.000 --> 12:53.000
It's an API structure with rewrite and delete capabilities

12:53.000 --> 12:54.000
on certain mouths.

12:54.000 --> 12:56.000
That's a thin interface.

12:56.000 --> 13:00.000
Sometimes to a KB store, or dynamically create

13:00.000 --> 13:03.000
credentials on the fly.

13:03.000 --> 13:07.000
OpenBow authenticates.

13:07.000 --> 13:10.000
User authenticates to openBow using some engine.

13:10.000 --> 13:14.000
OpenBow is used to token that token gets some mapping

13:14.000 --> 13:18.000
to ACL policies, and there's no concept of this long-term identity

13:18.000 --> 13:20.000
or ownership of a secret.

13:20.000 --> 13:25.000
It's a relatively API driven flat design.

13:25.000 --> 13:30.000
The core of the design then is to integrate with openBow

13:30.000 --> 13:33.000
to provide multi-tenancy and complete isolation

13:33.000 --> 13:37.000
of secrets via a trusted manager, which is GitLab Rails.

13:37.000 --> 13:40.000
And it's a familiar architecture to many of our customers

13:40.000 --> 13:44.000
who won Hashka vault clusters of their own.

13:44.000 --> 13:49.000
Each tenant, usually in owner of a repository,

13:49.000 --> 13:55.000
or organization, has the separate path area within openBow.

13:55.000 --> 13:58.000
Within the space they have an authentication engine,

13:58.000 --> 14:04.000
a JBUT off for authorizing pipelines access to secrets.

14:04.000 --> 14:08.000
Each project has its own KBB2 secrets engine,

14:08.000 --> 14:11.000
which stores the actual secrets.

14:11.000 --> 14:13.000
And it's stored in a structure format with custom metadata

14:13.000 --> 14:16.000
so that we know the scope of access

14:16.000 --> 14:21.000
and contextual information like descriptions and dates.

14:21.000 --> 14:23.000
Rails can, of course, read this metadata

14:23.000 --> 14:26.000
and provision ACL policies and JBUT off-rolls

14:26.000 --> 14:31.000
for all scopes when things change.

14:31.000 --> 14:36.000
When we add namespace support to openBow upstream,

14:36.000 --> 14:40.000
we'll provision each of these tenants in separate namespaces,

14:40.000 --> 14:42.000
and long-term we wish to add support

14:42.000 --> 14:45.000
for per name space, seal mechanisms,

14:45.000 --> 14:49.000
and encrypted key rings to provide gated data isolation,

14:49.000 --> 14:52.000
especially on GitLab.com.

14:52.000 --> 14:55.000
Within the core management space on the right,

14:55.000 --> 14:57.000
there's another authorization engine,

14:57.000 --> 15:00.000
the Rails, state of the TELF,

15:00.000 --> 15:04.000
used for this management interface.

15:05.000 --> 15:08.000
This gives Rails access to its own policy,

15:08.000 --> 15:12.000
but then also to set project and tenant policies

15:12.000 --> 15:17.000
within that ACL role collection.

15:17.000 --> 15:21.000
Authentication occurs by on more of a property based model.

15:21.000 --> 15:25.000
We already have IDC ID tokens issued by GitLab

15:25.000 --> 15:30.000
to pipeline workers that have metadata

15:30.000 --> 15:33.000
like the owner of the repository,

15:33.000 --> 15:37.000
branch the environment,

15:37.000 --> 15:41.000
and so we translate these tokens

15:41.000 --> 15:47.000
via the JBUT off-roll into concrete ACL policies

15:47.000 --> 15:49.000
based upon these properties.

15:49.000 --> 15:54.000
The policies then contain the list of secrets

15:54.000 --> 15:58.000
that that environment that scope that property has access to.

15:59.000 --> 16:02.000
This lets us use OpenBall as a single source of truth.

16:02.000 --> 16:04.000
For all secret management operations,

16:04.000 --> 16:09.000
there are no entries in the GitLab Rails database

16:09.000 --> 16:15.000
at all for secrets within OpenBall.

16:15.000 --> 16:18.000
And Rails is simply a management engine

16:18.000 --> 16:20.000
and a trusted token issuer,

16:20.000 --> 16:25.000
and does not store much other data.

16:25.000 --> 16:27.000
From a developer's perspective,

16:27.000 --> 16:29.000
this looks like the following.

16:29.000 --> 16:34.000
You're going to use the UI to create a new secret.

16:34.000 --> 16:36.000
It's going to be a nice interface.

16:36.000 --> 16:38.000
You're going to enter your name and your value over your secret.

16:38.000 --> 16:40.000
All that good stuff.

16:40.000 --> 16:43.000
You set some restrictions around the environment

16:43.000 --> 16:44.000
and scope.

16:44.000 --> 16:47.000
And then you'll save that.

16:47.000 --> 16:52.000
Then in your GitLab CICD pipeline configuration

16:52.000 --> 16:56.000
you'll reference the GitLab secret manager

16:56.000 --> 16:59.000
and the name that you set up on the left

16:59.000 --> 17:03.000
and GitLab will handle all of the rest.

17:03.000 --> 17:10.000
The management of the access in the deployment.

17:10.000 --> 17:15.000
So, a GitLab we're really excited about working on OpenBall.

17:15.000 --> 17:19.000
If you are too, we welcome all contributors of any sort.

17:19.000 --> 17:23.000
We have our community calls, went online.

17:23.000 --> 17:27.000
We have a roadmap vision for where we want to take the project

17:27.000 --> 17:29.000
as a community.

17:29.000 --> 17:32.000
We have various working groups working on

17:32.000 --> 17:35.000
adding support for things like game spaces,

17:35.000 --> 17:37.000
pieces, 11HSM modules,

17:37.000 --> 17:40.000
and horizontal scalability.

17:40.000 --> 17:43.000
If you like anything open-door related,

17:43.000 --> 17:45.000
please also share it on social media

17:46.000 --> 17:49.000
with colleagues, just great to build the community.

17:49.000 --> 17:53.000
If you're a customer of GitLab and you're interested in

17:53.000 --> 17:56.000
what we're doing, ask your account team about joining

17:56.000 --> 18:00.000
the beta program for our secret manager.

18:00.000 --> 18:03.000
I'm happy to take questions now, Lair.

18:03.000 --> 18:06.000
You can always find me at the GitLab booth

18:06.000 --> 18:09.000
afterwards, or we have stickers, or if you want to

18:09.000 --> 18:12.000
selfie with our little mascot, Bob Allen.

18:12.000 --> 18:15.000
We have a posh version of that outside, so.

18:15.000 --> 18:16.000
Thank you.

18:16.000 --> 18:17.000
Thank you.

18:17.000 --> 18:25.000
APPLAUSE

18:25.000 --> 18:29.000
So, the first question comes from the Matrix Room.

18:29.000 --> 18:33.000
Will GitLab support masking secrets coming from OpenBall?

18:33.000 --> 18:35.000
Masking secrets? Yes.

18:35.000 --> 18:38.000
Our existing Vault Enterprise integration,

18:38.000 --> 18:42.000
supports masking secrets from third-party

18:42.000 --> 18:46.000
secret managers, so that will continue for our

18:46.000 --> 18:48.000
native secret manager offering.

18:48.000 --> 18:50.000
Open them.

18:50.000 --> 18:53.000
Any other question?

19:04.000 --> 19:07.000
On the which subscription tier will this be in

19:07.000 --> 19:11.000
GitLab, so will it be in the open-source version?

19:11.000 --> 19:14.000
That's a little up in the air right now.

19:14.000 --> 19:19.000
I suspect it will be at least premium, but that is

19:19.000 --> 19:22.000
still being worked on and decided.

19:22.000 --> 19:23.000
Thank you.

19:23.000 --> 19:26.000
For the time being, but if we get a lot of interest,

19:26.000 --> 19:31.000
I don't know.

19:31.000 --> 19:35.000
The question was, was the question running

19:35.000 --> 19:37.000
off in the micro?

19:37.000 --> 19:39.000
Go repeat.

19:43.000 --> 19:44.000
Hello.

19:44.000 --> 19:48.000
When is general availability planned?

19:48.000 --> 19:51.000
General availability?

19:51.000 --> 19:53.000
Are there any plans at all yet?

19:53.000 --> 19:55.000
Yes.

19:55.000 --> 19:59.000
Later this year is our rough time line.

19:59.000 --> 20:03.000
The question was, is there a timeline for general availability of this

20:03.000 --> 20:05.000
at GitLab later this year?

20:05.000 --> 20:06.000
Hopefully.

20:06.000 --> 20:08.000
Not yet concrete.

20:14.000 --> 20:15.000
That's all.

20:15.000 --> 20:16.000
Very good.