I'm using spring-cloud-vault to retrieve the versioned kv from the vault server. When I'm using the environemnt.getSecret("key1") then it returns only the latest versions of key for example world2. Is there any way to retrieve the old versions of secrets by specifying the version number for a given key using spring-cloud-vault library?
#vault kv put secret/my-app key1=world1
Key Value
--- -----
created_time 2018-09-20T12:00:19.6136263Z
deletion_time n/a
destroyed false
version 1
#vault kv put secret/my-app key1=world2
Key Value
--- -----
created_time 2018-09-20T12:00:27.1820524Z
deletion_time n/a
destroyed false
version 2
Thanks for your help.
Spring Cloud Vault supports as of release 2.0 the versioned Key-Value API (key-value backend v2). There are two differences to the non-versioned Key-Value API (key-value backend v1):
The versioned Key-Value backend uses a different API. In particular, HTTP paths and the JSON payload are slightly different.
The versioned Key-Value backend is able to store multiple versions.
With Spring Cloud Vault, only the first aspect, differences in the API, were considered (see the related GitHub ticket for further details).
Spring Cloud Vault does not use the versioning aspect (i.e. reading an older secret version) but rather reads the latest secret version. I filed a ticket for using Vault's versioning features with configuration properties/the Environment. That ticket should be a good place to start a discussion about how such an integration could look like and how it could make the most sense.
Related
I am using a JBoss based vault to secure sensitive data such as the database credentials.
I use a Java based HTTP REST client to create distributed Kafka connectors but ended up with a security concern such that a request for the connector's "config" exposes the sensitive credentials in the response.
I referred this official documentation but could not get much help in the context of JBoss vault.
Any pointers or references that directly addresses this specific problem is very much appreciated.
Any references to alternate open source (and free to use) Vault based solutions would also be of great help.
You'd have to write code that implements the ConfigProvider interface of the Connect API, mentioned there.
You can browse Kafka source code on Github to see the existing File one, but that KIP (which references Hashicorp Vault) and the source files are the only such documentation for now.
Connect doesn't use JBoss, either, so you'd have to find a way around that
I have configured MongoDB 3.4.16 Enterprise version for native encryption following the Local Key Management method as mentioned in the documentation of MongoDB.
I find that, as mentioned in the tutorial I also get the encryption successful message on the command prompt which comes after the operation was successful:
[initandlisten] Encryption key manager initialized with key file:
My question is, how can I demonstrate the results to other people that with just these configurations the encryption has happened? Like for example, only if I can show the DB data file before and after applying these encryption configurations.
I don't have an answer, rather a comment. Be sure to take note of the notice at the top of the Local Key Management page.
IMPORTANT
Using the keyfile method does not meet most regulatory key
management guidelines and requires users to securely manage their own
keys.
The safe management of the keyfile is critical.
Without a dedicated key manager to store and manage keys, it is like leaving the keys to your house under your welcome mat. Since you are on Enterprise edition, use KMIP and deploy an encryption key manager. More on encryption key management for MongoDB here: https://info.townsendsecurity.com/mongodb-encryption-key-management-definitive-guide
I have configured my service fabric services to use Azure Key Vault for configuration. If, after the app is deployed, I change the config in Key Vault, how do I then restart the affected service so it can pick up the new config value?
Or is there another way altogether?
The best way to handle configuration on SF is use your application parameters file for this, if you use a continuous deployment pipeline like VSTS, you could use release variables to set these values for you and deploy a new version of your configuration file and let SF do the rest.
But in case you still need to use Key vault:
if you are using asp.net core, Using Azure Key Vault to store secrets are like loading configuration files, the values are cached until you reload it.
You can use the IConfigurationRoot.Reload() to reload the secrets from your key vault new values. Check it Here
The trick now is to make it automatically you have to:
Enable Key Vault Logging to track the changes, this will emit logs once you update the key vault. check it here and here .
And then:
Create an endpoint in your API to be called and refresh the secrets. Make it secure to avoid abuse.
Create an Azure function to process these logs and trigger the endpoint
Or:
Create a message queue to receive the command and the system read the message to refresh the settings
Or:
Make a timer to refresh on specific periods(I would not recommended this approach because you might end up with outdated config, but it is easy and useful for quick test scenarios, not production)
Or if you prefer more custom designed solution, you could create your own ConfigurationProvider based on KeyVault and do the cache logic according to your app architecture and you don't have to bother with the rest. Please refer to the Asp.Net source here for this.
The documented way to provide configuration to your services is by using the 'configuration' part of your application package.
As this is versioned, it can be upgraded, without requiring your services to be upgraded or even be restarted.
More info here and here.
Spring Boot - 2.0.0.M3
Spring cloud - Finchley.M1
I want to know if someone is using Spring Cloud config server with both vault and git support in a production setup using Database storage backend.
I have evaluated Spring cloud config using vault and contemplating whether to go for Oracle JCE to encrypt username/pwd or Vault and seek suggestions on the same. we are working on Springboot/microservices.
Following are my findings -
Vault will introduce an additional layer and thus will introduce additional usecases of security, auditing while communicating with Vault.
Spring cloud Config actuator endpoints are broken for the milestone release at this point for generation of encrypted values and /encrypt /decrypt may not work if we go for Oracle JCE support so we generate encrypted values through stable versions.
We do not wish to use consul server and are trying to use Cassandra as Storage backend.
I used Vault Authentication backend using AppRole and generated a Token (different from root token as it's unsafe to use the same) with read permissions. However, Spring Cloud config at the moment support only Token based authentication from client side. That means we first generate token from Vault and then pass it as commandline/env variable.
Some additional points of concern are expiry of token (though we can have non-expiry token not sure about pros/cons), restarts, safety issues, instantiating new microservices. There is no provision of dynamic tokens/authentication at cloud config side.
For milestone release i found that the client side encryption/decryption is not working as of now using recommended inclusion of RSA jar. Here is the ticket i opened.
https://github.com/spring-cloud/spring-cloud-config/issues/805#issuecomment-332491536
These are some of my observations, please share your thoughts if there is any case study/whitepaper that address spring cloud config vault usecases, setup and challenges for production micro-services environment.
Thanks
Thanks for reaching out to me. One think I would state is that the App Role backend utilizes two distinct tokens, and indeed spring-cloud-config-vault does indeed support this functionality, see: http://cloud.spring.io/spring-cloud-vault/single/spring-cloud-vault.html#_approle_authentication. I leverage vault in the same way I leverage config server, as per the documentation. I don't encrypt any values in my config, I just don't put them there. I put the secret values in vault and let it serve config. As long as keys don't collide, you don't have to mess with anything, otherwise you may need adjust the priority so vault wins, again see the documentation that I pointed to above. I wouldn't mess with encryption/decryption in spring-cloud-config personally. Because you have to check the keys into SCM or distribute them to your teams for local development, you lose the value of having these keys IMO.
Thanks Spring Cloud vault does support but not Spring cloud config with Vault. Only way seems to be passing X-Config-token from Microservice to Config Server. We are bit skeptical with this part of generating tokens manually or through script. Especially with containerization and when new MS instances will be spawn. Not sure about this approach especially in production setup.
I am looking to access a local instance of Couchbase Server through its REST API. The HTTP GET requests are sent from Java.
The problem I am currently running into has to do with authorization.
Specifically, I have managed to use Couchbase's Basic Authorization, but only by obtaining the hashed credentials (bG9jYWw6dHdlZXRzOnBBc3Mx in the example linked to above) by monitoring a Couchbase browser session using Chrome's developer tools and inspecting the request headers.
Now, another Couchbase article mentions that Couchbase uses SHA-1 in compliance with SCRAM. However, no mention is made of how to obtain the 'salt' and 'iterations' parameters from Couchbase. Which, I assume I need to go from the credentials to the challenge solution (i.e. hashed string)
So, the question is as follows: how to get from the credentials (user="local:tweets", pass="pAss1") (from the example of the first link) to bG9jYWw6dHdlZXRzOnBBc3Mx?
Thanks in advance,
Thomas
SCRAM SHA-1 support is only for the Data (K/V) service and only through certain Couchbase SDKs which use the memcached binary protocol. The Java SDK does have support for SCRAM SHA-1.
The REST interface you appear to be using is N1QL's API. That does not support SCRAM SHA auth.
If you're looking to give some other application HTTP access, my recommendation would be to write a small Java app with Spring Boot or the like and use the Java SDK from there. Then you have complete control over how auth is done at the REST interface. A colleague wrote one of these just the other day. Note that even in this case, the Java SDK won't be using SCRAM when running N1QL queries, but you can use that as a point of control.