The standard way to add env. specific config settings is to use OSGi config files and the editor. The problem is that the editor is disabled for Cloud. If we put secrets in git, any developer can access production systems.
how can we get round this? Is there a standard out of the box way to include env specific values which are not in Git, which the backend devs can use for integrating with banking systems etc?
This page:
Says this:
When to use secret environment-specific configuration values
Adobe Experience Manager as a Cloud Service requires the use of environment-specific configurations ($[secret:SECRET_VAR_NAME]) for any secret OSGi configuration values, such as passwords, private API keys, or any other values that cannot be stored in Git for security reasons.
Use secret environment-specific configurations to store the value for secrets on all Adobe Experience Manager as a Cloud Service environments, including Stage and Production.
So there appears to be a mechanism, but there is no mention of how this mechanism works or is used. how do we set the values?
Solved! Go to Solution.
Views
Replies
Total Likes
@TB3dock Please use the syntax provided in the link you shared to use a variable (secret or dev env variable) in your config and set these values using cloud manager
Hi @TB3dock,
You can use the context-aware configurations to add these values into any environment. Please note that these can be authored as well as sent via code.
Thanks,
Kiran Vedantam.
Hi @TB3dock
You can set the environment specific values using either API or using the command Line.
Please see the below links for more details about API and Command Line:
Thanks!
@TB3dock Please use the syntax provided in the link you shared to use a variable (secret or dev env variable) in your config and set these values using cloud manager
Hi, thanks for the reply.
]
This solution doesnt seem to make sense or solve the problem.
According to the docs, if you "push" a setting to an env, it will re-deploy that env. So we assume:
Also, its extremely risky to use command line to push secret settings to each env, its easy to get wrong. We don't own the pipeline, thats managed by another company. We don't want them to access the secrets. If they put command line to add secrets into the pipeline,then that company now has the secrets, so we would be back to square one. We dont see how this system helps. We need something like Azure KeyValut, where one trusted person can add a key which is stored encrypted, noone can ever view it, and it doesnt require a redeployment or reboot to add or update a variable.
Views
Likes
Replies