I have created AKS based application deployment where all the environment variables of application are defined in app-configmap.yaml file. This file is refered in deployment.yaml file.
I would like to store all the credentials those are mentioned in app-configmap.yaml file as environment variable into secrets in keyvault and finally from keyvault , it will be refered in app-configmap.yaml file.
I need help to understand it step by step by which I can implement it
In general I would not recommend to use secrets as environment variables or with configmaps.
With the AZURE KEY VAULT PROVIDER FOR SECRETS STORE CSI DRIVER you should use the secrets as file mounts inside the pod that really needs the secret. With this you can also rotate secrets on-demand or sync own TLS certs etc.
Pro is you dont need AAD-Pod-Identity bcs the CSI handles auth on its own.
Related
I have been tasked with adding application-level file-at-rest encryption to files stored in an S3 bucket and accessed from within a Docker container in ECS.
I have been told that the default server-side encryption of the S3 bucket is insufficient and that I should implement additional encryption of the files at rest at the application level using AES encryption.
We are currently using GPG asymmetric encryption for files coming from upstream and going downstream. Our private key and the downstream application's public key are both obtained from Secrets Manager.
For files at rest, it seems appropriate to use a symmetric key also stored in Secrets Manager.
Anywhere I search, however, it seems that the intended use of AES encryption is typically meant for files that are stored on the server where they are being used. Typically, to my understanding, a passphrase is provided and used to secure a symmetric key stored somewhere on the server by gpg.
Since the application is running within a Docker container, it does not seem appropriate for the key to be stored only on the application server as it would be lost when the container is rebuilt and deployed.
How can I accomplish AES encryption/decryption of the files in the bucket with a pre-existing key that is stored outside the container (i.e. Secrets Manager in this case)?
Azure Container Instance is deployed in VNET and I want to store my keys and other sensitive variables in Key Vault and somehow access to it. I found in documentation, it's currently limitation to use managed identities once ACI is in VNET.
Is there another way to bypass this identities and to use Key Vault?
I'm trying to avoid environment variables and secret volumes, because this container will be scheduled to run every day, which means there will be some script with access to all secrets and I don't want to expose them in script.
to access the Azure Key Vault you will need to have access to a Token, are you ok storing this token into a k8s secret ?
If you are, then any SKD or CURL command could be use to leverage the Rest API of the Key Vault to retrieve the secret at run time : https://learn.microsoft.com/en-us/rest/api/keyvault/
If you don't want to use secret/volumes to store the token for AKV it would be best to bake in your token in your container Image and maybe rebuild your image everyday with a new token that you could manage its access I AKS at the same time within your CI process
I'm looking for a way to use docker secrets and for all case where I don't need to update the stored value of the secret that would be a perfect situation but my app is having multiple services which are having 3 legged OAuth authorization. After successfully obtaining all tokens a script is collecting all tokens then creating secrets out of them and executing the config of my docker.compose.yml file with the container using those secrets. The problem is when the tokens have to be refreshed and stored again as secrets. Docker secrets does not allow updating the secrets. What would be the possible workaround or better approach?
You do not update a secret or config in place. They are immutable. Instead, include a version number in your secret name. When you need to change the secret, create a new one with a new name, and then update your service with the new secret version. This will trigger a rolling update of your service.
I want to build a microservices software with JHipster. I'm running jhipster-registry:v3.2.4 into Docker, i also have a microservice application (create with generator 5.0.1) but i do no generate a gateway application.
I set the profiles in docker-compose.yml with: dev and native
I setted the JWT Secret in Docker Compose file.
I added configurations files into : central-config folder
I setted the jwt for my microservice into all possible *.yml files
but on the registry UI, when i'm trying to access microservices logs or metrics, i got an Exception : Invalid JWT Signature.
As you use the native profile, you can use a config file by setting
SPRING_CLOUD_CONFIG_SERVER_NATIVE_SEARCH_LOCATIONS=file:./config/ in your compose .yml and in a config folder, you add an application.yml file with
jhipster:
security:
authentication:
jwt:
secret: your secret
You must add;
jhipster: security: authentication: jwt: secret: or jhipster: security: authentication: jwt: base64-secret: (JHipster v5.3.0+) in application.yml or application.properties.
A little reminder. Secret must be longer than 256 bits.
I'm wondering if anyone has experience using Dropwizard and Vault together? I'm looking for a solution where I can keep my DB and other passwords in Vault instead of the dropwizard .yaml configuration. I'd also like to be able to start my service up and be prompted for the Vault key and not place any secrets in any config files. Any help is greatly appreciated.