Inside the secrets manager I have create a secrets group ("accessData") and stored an username / password as Shared Secret ("SAPcredentials") in this group.
In my mule flow I now would like to access these, but I haven't figured out how. I hoped for a method smiliar to the way parameters are handled in dataweave or global configurations, e.g.
p('accessData.SAPcredentials')
or
${accessData.SAPcredentials}
But apparently that's wrong - any suggestion how to do it right?
Anypoint Secrets Manager documentation states that only can be used for some services:
Secrets manager supports the management of TLS context for the following services:
Runtime Fabric ingress
You can store TLS artifacts in secrets manager and then configure Anypoint Runtime Fabric ingress with the secret reference.
API Manager in CloudHub
You can store the TLS artifacts in secrets manager and then configure Anypoint API Manager with the secret reference.
It doesn't look like it is possible to use it from a generic Mule application.
Related
We currently have a cert manager instance in IBM Cloud and have certificates ordered via Lets Encrypt and using the certs with our client to site vpn service . As the cert manager is getting deprecated in favour of secrets manager , we plan to create public engine in Secret manager using same Lets Encrypt CA.
In the ACME creation tool, we have the option of tageting Let's Encrypt prod and staging. Can anyone throw light on which target needs to be chosen?
https://github.com/ibm-cloud-security/acme-account-creation-tool#supported-certificate-authorities
Also, once LE is integrated with Secrets manager , will the certificates be able to be auto renewed?
LE staging is for testing your setup. Once everything works you should use production. See https://letsencrypt.org/docs/staging-environment
Secrets Manager supports secrets rotation, including automatic renewal of certificates. Some conditions must be met. I recommend to check "Automatically rotating secrets" in the Secrets Manager documentation. I have not tested it, but from reading it, LE is supported with domain validation.
I am using jboss/keycloak docker image (uses wildfly as app server) and we are leveraging keycloak as an identity broker and user federation. I want to store the keycloak specific secrets in hashicorp vault, and basically access these secrets at runtime.
The identity service is written in java where I have created a customized vault (hashicorp) provider using the vault spi. I have used this extension to add the vault provider.The provider is integrated now, and I am able to see it in the provider list. Wanted to check how can I store and retrieve keycloak secrets (like realm ids, ldap credentials, external tokens etc) from this vault.
BACKGROUND
We are about to set up a deployment server that will be used to manage Azure resources. The deployment server will run pre-defined PowerShell scripts and deploy ARM-templates.
This article describes how to use service principals and keys vaults so that the application that runs inside the deployment server securely can execute deployment scripts.
PROBLEM
Frequently, the deployment server will be updated with scripts, new pipelines, different types of configuration, code snippets, templates etc. When changes are made on the deployment server, we do not want the secrets to being exposed in any way.
A JUST IN TIME APPROACH – CUSTOM ACCESS KEY API
The functionality we are looking for can possibly be implemented with a custom access key API with the flowing workflow:
In a service request portal, a deployment ticket is signed by an
approver
The deployment server receives the signed deployment ticket
The deployment server sends the signed ticket to a custom access
key API and receives a temporary service principal and access key
The deployment server executes scripts (with the temporary service
principal)
The temporary service principal and access key is automatically
removed
WHY A CUSTOM ACCESS KEY API?
The custom access key API adds the following capabilities:
By comparison to a deployment server, the API has a smaller footprint and we believe that updates to the service will be rare and can be done in a very controlled manner.
The API can give access to the deployment server based on the exact need (subscription, resource group, etc)
The API can use digital signatures to verify the original approver of the ticket
RECOMMENDED APPROACH?
What is the recommended approach to implement just in time access for a deployment server?
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.
I want to keep my smtp login information private. And its a hassle to edit application-prod.yml every time I have to deploy to production.
What is the correct method to avoid storing sensitive details in application-prod.yml on github ?
Many different ways depending on where and how you deploy to:
Don't store application-prod.yml in git and don't package it in your jar
Don't store secrets in application-prod.yml, use environment variables or command line options. See Spring Boot doc.
Encrypt secrets using git-crypt in application-prod.yml
Store secrets in external Spring Cloud Config Server (e.g. JHipster Registry) or HashiCorp Vault
and many other ways...