Investigating an Oracle Secret Backend

[gdavison]

My company is interested in using Vault, but our primary database is Oracle. I'd like to work on creating a secret backend for Oracle, but there are several issues that make it problematic. I'd like to get some thoughts from Vault project people before going too far down the rabbit hole.

Firstly, Oracle does not publish the wire interface to their database, so the only way to communicate with Oracle is through their binary blob driver library. On some platforms, it looks like a static library is available.

In order to use the Oracle libraries, at least some use of cgo would be required. Rather than build all of Vault with cgo, it would make sense to use something like go-plugin to isolate that portion. Judging from comments on both the Vault and go-plugin pages, go-plugin is not quite ready for prime-time use in Vault.

In general, does the approach make sense? Use would have to be at-own-risk until plugin issues are resolved, of course.

[vishalnayak]

@gdavison This is not a new request and is being tracked by #1460.

[gdavison]

@vishalnayak #1460 is closed. Should it be open if it's tracking an issue?

[vishalnayak]

@gdavison Not sure why it is closed. Probably for not getting more eyes on it and have people work on the same feature in parallel.

[jefferai]

Hi @gdavison ,

go-plugin support in Vault is very much on our roadmap currently, and this is one of the primary use-cases, as we've wanted Oracle support and cgo is something we don't want in Vault generally. We know how we're going to do the go-plugin enhancements; one of the things we haven't locked down yet is what the plugin interface looks like, although we have some ideas.

If you're interested in working on an Oracle backend, coding one up against the current backend interface would probably get you pretty far for the eventual plugin interface as we'll clearly need to satisfy a number of the same needs. In the mean time you would have a backend you could use in your Vault build.

I'll reopen this for now rather than reopening #1460 as you being active makes it more current. :-) If you have questions let us know and we can also let you know progress on the plugin interface as it takes shape so you can test. Plugins won't be in 0.7 but might appear somewhere in the 0.7.x line.

[jefferai]

@gdavison I thought I answered all of them?

[gdavison]

@jefferai your comment wasn't there when I replied. Once I saw your comment, I deleted mine. You definitely answered what I was looking for, thanks!

[gdavison]

@jefferai I have an Oracle backend coded. Should I submit a work-in-progress pull request?

[jefferai]

Hi @gdavison ,

You should discuss with @briankassouf as he has been working on both our combined database backend and its plugin support. Both are getting close!

[briankassouf]

Hi @gdavison

That's great news! The plugin functionality is also getting close. It would be nice for this backend to be the first plugin database type supported. The WIP interface for a plugin is currently:

type DatabaseType interface {
 	Type() string
 	CreateUser(statements Statements, username, password, expiration string) error
 	RenewUser(statements Statements, username, expiration string) error
 	RevokeUser(statements Statements, username string) error
 
 	Initialize(map[string]interface{}) error
 	Close() error
 	GenerateUsername(displayName string) (string, error)
 	GeneratePassword() (string, error)
 	GenerateExpiration(ttl time.Duration) (string, error)
 }

Let me know what you think! My work-in-progress pull request is #2200.

[gdavison]

Hi @briankassouf, I'm on the road, so I haven't had a chance to take much of a look through the code on your PR. One thought I have, however, is about the CreateUser() function: each database has its own weirdnesses around usernames and passwords, so I think that it would be better to have each plugin generate those internally.

I'll have more of a chance to take a look Monday and rebase and create my WIP PR for the non-plugin version. Next I'll port it to the plugin interface.

[jefferai]

@gdavison That's what the GenerateUsername, GeneratePassword, and GenerateExpiration functions are for!

You should work closely with @briankassouf ; one of the reasons for having a plugin interface is to avoid cgo-based databases in the main tree, so you can skip the PR for the non-plugin version; Oracle is the main initial reason we're adding plugin support in the first place :-)

[gdavison]

Well, that's embarrassing, I skimmed right over the GenerateX() functions. I plead vacation brain :)

[jefferai]

@gdavison If it helps at all, someone worked on an Oracle backend at https://github.com/binxiong/vault

In case any code there might be of use.

[gdavison]

Thanks, @jefferai, I'll take a look to see if there's anything I should "borrow". I've had working code via cgo for a couple weeks, but haven't ported it to the plugin interface yet.

[yeroc]

Is there any update on this?

[jefferai]

@yeroc @gdavison has been working on it.

[lscoughlin]

Did this die?

[gdavison]

Nope: https://www.vaultproject.io/docs/secrets/databases/oracle.html