Who dat in MySQL?

Vinnie Ramirez
HashiCorp Solutions Engineering Blog
7 min readMay 13, 2019
A HashiCorp Vault blog

The non-tech part

In the fast paced world of public clouds, DevOps, schedulers, Serverless, blockchain, and quantum cryptography we sometimes have to slow down and remember some of the problems that have already been solved.

As a solutions engineer at HashiCorp, I have the privilege of meeting with technologists and executives from the largest companies in the world. Recently I was presented with an interesting question from one of our enterprise customers regarding our product Vault. I will get into the question and the technical solution options within this blog, but first I want to slow down and reflect on the root of the question that was asked. The customer asked me how to use one of our products to improve a legacy security process that is very commonplace within large enterprise companies and even the youngest of startups. The light bulb moment for me was when I realized that I had provided my customer with a long list of ingredients but what they really needed was a recipe. Literally, tell us how to use your thing, to do this thing.

I was so humbled by this encounter. I asked my customer how soon they needed the answer (the recipe). We scheduled a follow up meeting before the call had ended and I quickly went to work creating a detailed answer for the problem. In the tech world this stuff is so complicated and moving so fast — sometimes we just need to slow down and make sure we are delivering the recipe, not just the ingredients.

The Tech Part

As promised this blog is focused on the HashiCorp Vault security solution.

The Question:

“How can HashiCorp Vault help improve the workflow for database administrators that need privileged access to their databases, and non-admin users, or dependent systems, that need non-privileged access to databases?”

Huh? Hasn’t this problem been solved years ago? Wasn’t that the whole Privileged Access Management (PAM) wave of tech solutions? Well the answer is sort of. This age old problem has led to some pretty standard ways of operating that all boil down to create an account that has “god” rights, then protect that account username and password. Only let people with a need to know use the privileged account, and put some process in place for these users to “check out” the username and password when they need it to do their job. This problem exists for all IT systems, but this blog will only focus on the database workflow. Specifically humans that need access to a database.

Let’s look at the ingredients:

  • Humans
  • Databases
  • Sensitive Data
  • Username & Password
  • LDAP or Active Directory
  • HashiCorp Vault

Restate the problem:

Database administrators need privileged access to their databases and database instances.

Non-admin users or dependent systems need non-privileged access to databases or database instances

A common practice has been the use of Static DB credentials (often shared ) for admin & non-admin purposes.

This practice introduces security risks if static credentials are compromised.

The audit trails get fuzzy for who or what accessed a database using a static credential.

Database admins don’t really need to read the data in the databases to do their job.

Rotation of static credentials is not done on a frequent basis and can be disruptive.

The Solution:

Let’s break it down:

HashiCorp Vault database secrets engine with support for the most widely used databases (Cassandra, Influxdb, HanaDB, MongoDB, MSSQL, MySQL/MariaDB, PostgreSQL, Oracle, & Custom) . Create dynamic usernames and passwords, controlled by an ACL policy, with a short time-to-live.

Transit secrets engine encryption and decryption, signing, hashing, HMAC, etc. Only those with a need to know can read the data in a database. Vault Transit secrets engine can encrypt and decrypt sensitive data in databases, creating a security posture where not even a DBA can read sensitive data.

Control Groups add an additional layer of approval for highly sensitive datasets, heavily regulated environments, GDPR, etc. If DBA’s need “god” rights to do their jobs, a human or multiple humans need to approve that request, every time!

Sentinel Policy-as-Code enforces corporate policies such as trusted CIDRs, working hours, change windows, etc.

Control Groups and Sentinel policy-as-code, are enterprise features of Vault.

The database security recipe works across private datacenters, public clouds, and schedulers. Just add water ;)

Let’s get cooking

I don’t want to trivialize the level of effort it takes large enterprises to be successful at implementing, operationalizing, and consuming HashiCorp Vault at scale. We recommend a crawl/walk/run approach to our solutions.

In the case of HashiCorp Vault and the database security recipe, start to crawl by testing out Vault Open Source in a non-production setting against your favorite database flavor. Dynamic credentials are a major shift that will require education and buy-in from users and developers in your organization.

Once you have a good feel for how dynamic credentials work, start to explore the Transit secrets engine. This concept can prove to be a little disruptive to current database schema constructs specifically when it comes to reporting or queries that key off of sensitive data. Take for example a database query based on social security numbers. In a world of Encryption-as-a-Service, where we want to protect sensitive data like SSN’s by encrypting them in our database tables, we can’t query off of them anymore. This may require some additional non-sensitive data to query against like a unique customer ID, patient ID, etc.

The hardest part about moving out of the Vault crawl phase is knowing when you are ready to walk. Like any new solutions that have an impact on current processes in an enterprise, set yourself up for success early on by including as many people as possible. You may think your team is ready to start walking with HashiCorp Vault just to be met with fierce resistance from your Security team, DBA team, and Operations team that were un-aware of your sandbox testing. Now you have a stalled project on your hands that may never see the light of day. That being said, you know you are ready to walk when you have a successful project on your hands that is ready to go into production at some level to start delivering value back to your business. This could also coincide with the inclusion of other teams, but always be careful with paralysis by analysis syndrome. If including too many teams in early stages creates a blocker for your sprint, or project timeline, by all means choose the agile path.

Some enterprise customers have to make all-in decisions to move the ball down the field. If multiple solutions in the organization are causing fragmentation and ultimately slowing down the business, go all-in. Your competition is probably already using HashiCorp solutions and learning how to deploy their software faster, on-premise, or in public clouds.

Whatever path makes the most sense in your organization to get beyond the crawl and walk phases (stories will vary) knowing when to run is pretty clear. If you are facing some nasty audit findings that require immediate remediation, RUN. If your team has moved beyond the MVP and developed a solution that delivers value or a competitive feature, RUN. So what does run actually mean here.

It means get your organization’s software into production as quickly as possible. HashiCorp has several resources available to help our enterprise customers run.

  • Meet your local HashiCorp Solutions Engineer
  • Attend a HashiCorp User Group (HUG) or one of our events
  • Support (oh yeah, forgot about that)
  • Training (free & paid versions)
  • Enterprise Architecture services
  • Professional Services (starter packs to long-term implementation consulting)

Our customer’s success defines our success. Let HashiCorp help you RUN!

New to HashiCorp Vault?

Follow this link for a guided exercise that can be run on your local machine to get some hands-on experience with this use case.

Hands-On exercise

We also have FREE TRAINING on our Learn portal. Here you will find a range of self guided exercises specific to each solution.

There is no barrier to entry for HashiCorp Vault, or any of the HashiCorp solutions, as they can all be used in the Open Source.

Well, I take that back. The barriers to entry are first learning what HashiCorp solutions can do, why they do what they do, and a good recipe!

Thank you for reading my blog. Just a normal dude that works at a very cool software company. — Vinnie

Find something you’re passionate about and keep tremendously interested in it. — Julia Child

See you at HashiConf

HashiCorp is Hiring!

--

--