9 posts tagged with "technical"

This is the fourth part of a multi-part series on OpenBao's features.

Last time we talked about how to declaratively configure audit devices and initialize OpenBao. We saw how this made integration of OpenBao in a wider ecosystem or product (such as EdgeX) easier.

Like the last part, this part focuses on the operator experience, but for consumption of OpenBao's plugins: auth methods, secrets engines, auto-unseal devices, and more.

Our motivation here is to build towards a more OpenTofu-like, extensible ecosystem. Easier consumption, community-maintained plugins, and a future plugin registry will lead to more developers writing plugins and expand the usefulness of OpenBao for everyone.

This is the third part of a multi-part series on OpenBao's features.

In the past few parts, we talked about low-level technical features that OpenBao core maintainers and plugin authors can take advantage of to make secrets management safer and more scalable.

This part focuses on something that applies to operators of OpenBao: better operator experience for initial configuration. We focus on one question:

This is second part of a multi-part series on OpenBao's features.

Today we focus on transactional storage. While the earlier blog posts focused on the what and how of transactions in Raft, this post will focus on the measurable impact of transactions in OpenBao and their lack in Vault. We will demo some possible ways of creating snapshots which cannot restore and are not consistent on Vault and show how we used transactions to achieve consistency on OpenBao.

This is the start of a multi-part series on OpenBao's features.

Nearly every single networked interface returning a list of results supports subsets. SQL supports the LIMIT and OFFSET keywords, along with a rich language for filtering returned results. Google Cloud KMS APIs supports pageSize, yielding a nextPageToken, for iterating over multiple pages of results.

Many resources in Vault and OpenBao return lists: KVv2 secrets, PKI's certificate lists, SSH's roles, and more.

Paginated lists were shipped in OpenBao v2.0.0 as our very first feature in our very first release!

So, why doesn't Vault support paginated lists?

Summary​

In this blog post, I will give you an overview of the new Horizontal Scalability feature of OpenBao, its (current) limitations and planned future developments. In the second part, I will show some benchmarks to see in which cases the new feature helps (spoiler: it works best in read-heavy workloads, but doesn't improve write-heavy workloads).

As the OpenBao community starts development on Namespaces and the Horizontal Scalability Working Group has its kickoff, I wanted to take the opportunity to put forward a blog post describing how these two groups' work can compliment each other and provide an alternative path forward other than Vault Enterprise's Performance Secondary and Disaster Recovery clustering modes.

Overview​

OpenBao, like its upstream, favors the raft internal storage engine. While more complex than relying on a database for replication, this storage engine allows us to have lower latency on read operations, because it uses a local K/V implementation based on B+-trees. For workloads with low writes but high reads (typical of most uses of K/V secrets), this trade off allows for the best performance.

An earlier blog post talked about the availability of transactions in the main branch, this post will focus on the technical details of implementing transactions.

Recently we merged the last of the transactional storage pull requests, including PostgreSQL support!

OpenBao and upstream lack server-side cross-plugin communication.

As recently seen with an OIDC feature, this shortcoming often needs to be worked around on the client side, potentially exposing sensitive information.

There's usually two paths discussed for cross-plugin communication:

1. Requests bound under the context of the original user token.
2. Designing some other authorization system or an internal API based design.