Vault Code Analysis with Mule Linter

The popularity of the public cloud has been growing steadily in the recent past. Already, many corporations have migrated to the public cloud. This shift has brought up a major concern: what’s the best way to secure data? How do you prevent exfiltration or unauthorized access?

HashiCorp Vault is a popular product designed to give users better control and management of their secrets. It is a straightforward way of meeting the security standards in the cloud. In cybersecurity a secret refers to any sensitive credentials that an organization needs to tightly control, monitor, and limit access, that people with authorization can use to unlock sensitive data.

A vault secret could be an API key, RSA token, SSH key, OTP or password. With HashiCorp Vault, you have Spring Cloud Vault Config that offers client-side support for managing external secret properties.

Modifying the Source Code

To handle secrets on MuleSoft AnyPoint Runtime, you can either use the HashiCorp Vault Connector or the Vault Properties Provider. If all you need is to retrieve secrets from Vault, and the secrets don’t change often, the Vault Properties Provider should suffice.

However, if you’ll need to encrypt data, write secrets, or retrieve values that change frequently, then the Vault Connector is preferable. Both the Vault Connector and the Vault Properties Provider are open source: you can modify the source code to better align it with your Mule project.

In the event that you modify the code, Mule Linter would be the perfect tool to use to check your code for patterns that don’t align with code conventions.

A linter refers to a source code analysis tool that looks for patterns in code that don’t align with accepted coding conventions. Linting prevents errors and improves the quality of code by following best programming practices. A lint tool is somewhat a static code analyzer. PMD, FindBugs, and Checkstyle are good examples of Java code analyzers.

The Mule Linter is a source code analyzing tool that enforces a baseline set of rules for Mule projects. These rules that it can enforce include useful logging messages, proper use of pom and property files, and the standard structure of a project, just to name a few.

Vault is an encryption as a service solution. It has a centralized key management system that simplifies how you encrypt data, both at rest and in transit across data centers and clouds. By design, Vault solves the decentralized secrets management problem. It has several encryption keys used for key rotation in case there is a compromise or potential leak.

Every time hackers attack the system, the need for unending credential rotation arises. Instead of setting database credentials as environment variables, you should design the system such that applications ask Vault for the database credentials.

Everything in Vault, including policies, is path-based. Policies are a declarative way of granting or forbidding access to certain operations and paths in Vault.

Writing a Policy

When writing a policy, the first step involves gathering policy requirements. The policy requirements define what an admin user should be able to do. This includes:

• The ability to read the system’s health check
• Manage and enable authentication methods in Vault
• Manage Key-Value secrets engine that’s enabled at secret/ path
• Have the permissions to create and manage ACL policies
• Add an admin policy definition in the admin-policy.hcl file

An admin-policy.hcl looks like this:

$ tee admin-policy.hcl <<EOF # Read system health check path “sys/health” {   capabilities = [“read”, “sudo”] } # Create and manage ACL policies broadly across Vault # List existing policies path “sys/policies/acl” {   capabilities = [“list”] } # Create and manage ACL policies path “sys/policies/acl/*” {   capabilities = [“create”, “read”, “update”, “delete”, “list”, “sudo”] } # Enable and manage authentication methods broadly across Vault # Manage auth methods broadly across Vault path “auth/*” {   capabilities = [“create”, “read”, “update”, “delete”, “list”, “sudo”] } # Create, update, and delete auth methods path “sys/auth/*” {   capabilities = [“create”, “update”, “delete”, “sudo”] } # List auth methods path “sys/auth” {   capabilities = [“read”] } # Enable and manage the key/value secrets engine at `secret/` path # List, create, update, and delete key/value secrets path “secret/*” {   capabilities = [“create”, “read”, “update”, “delete”, “list”, “sudo”] } # Manage secrets engines path “sys/mounts/*” {   capabilities = [“create”, “read”, “update”, “delete”, “list”, “sudo”] } # List existing secrets engines. path “sys/mounts” {   capabilities = [“read”] }

 

Authenticate Applications with Role ID and Secret ID

To authenticate your applications, you can use Role ID and Secret ID. Role ID is more or less the username of an application, meaning one application can show up severally with the same Role ID.

On the other hand, Secret ID is more or less the password you will need to login to Vault. Unlike Role ID, a Secret ID is unique and will often have expiration, usage limit, and TTL, as ways of limiting access.

Here is an example of how you login to Vault using the Role ID, and Secret ID:

$ vault write auth/approle/login role_id=${ROLE_ID} secret_id=${SECRET_ID} Key                     Value —                     —– token                   87e9d662-2f9d-5cc5-a7eb-b3e5ed76d887 token_accessor          3e9a58e5-4ea5-fe1c-d3fc-180017b63e98 token_duration          1h token_renewable         true token_policies          [default hello-world] token_meta_role_name    hello-world

 

It is important to note that the password in your configuration is the password that stores the application secret in whichever database that is serving as the storage backend. It is not the secret of your application.

You can use the kv secrets engine to store arbitrary secrets in the physical storage configured for Vault. Key Names are always string values. In case you include non-string values, they will be turned into strings. That said, there is a way you can preserve your non-string values. You do this by writing the key/value pairs using HTTP API or a JSON file. 

AVIO Consulting provides the formula to accelerate digital evolution and innovation. We offer thought leadership and proven practices for modern software development as well as a highly productive delivery team focused on enterprise integration with the MuleSoft platform.