Hi All,
I want to know if i can directly use environment variable for token in yaml file for splunk setup.
I'm trying to setup splunk with aem as cloud:
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi @rawvarun,
Yes, you typically can reference environment variables in your YAML configuration, but it depends on how the YAML file is processed by the AEM environment or the underlying system.
When setting up Splunk with AEM as a Cloud Service, the Adobe Experience League guide usually suggests configuring logging or data forwarding using files like splunk.yaml or through the Adobe Cloud Manager environment.
To keep things secure, it’s best not to hardcode sensitive tokens - like the Splunk HEC token - directly in the YAML file. Instead, using environment variables is recommended because it helps keep these secrets out of your source code and makes them easier to manage securely.
Plain YAML files themselves do not support environment variable expansion by default.
YAML is just a data serialization format. To inject environment variables into YAML files, the application reading the YAML must support environment variable substitution.
In AEM as a Cloud Service:
Adobe Cloud Manager supports injecting environment variables into your runtime environment.
You can define environment variables in the Adobe Cloud Manager UI or via the Cloud Manager API.
Your application code or service that reads the splunk.yaml should be able to read these environment variables at runtime.
Common approaches:
Option 1: Use placeholders in YAML and replace them during build/deploy process.
Eg. in splunk.yaml:
${SPLUNK_TOKEN}
And then during deployment, a script or the platform replaces ${SPLUNK_TOKEN} with the actual value from environment variables.
Option 2: Read the token directly from environment variables in code/config.
If the YAML is for a service that supports environment variable expansion (like some Docker setups or Helm charts), it may work directly.
Per Adobe docs generally recommend not hardcoding tokens in configuration files but managing secrets using:
Adobe Cloud Manager environment variables for sensitive data.
Using AEM's secure vault or secrets management (for local dev and some environments).
Injecting tokens securely during deployment.
Hope that helps!
Can you provide me details related to option 1 to read environment variable?
Views
Replies
Total Likes
You write your YAML configuration file with placeholders for sensitive values (like your Splunk token), and during the deployment or build process, those placeholders are dynamically replaced with actual environment variable values.
Write your YAML with placeholders
Instead of putting the real token in the YAML file, use a placeholder syntax. For example:
splunk:
hec_token: ${SPLUNK_TOKEN}
hec_url: https://splunk-instance:8088/services/collector
Here, ${SPLUNK_TOKEN} is a placeholder that represents the environment variable you want to inject.
Define the environment variable in your deployment environment
In Adobe Cloud Manager (or wherever you deploy), set an environment variable named SPLUNK_TOKEN with your actual secret token value.
Use a tool or script to replace placeholders before runtime
Before the application or service uses the YAML file, a build or deployment script reads the YAML, finds placeholders like ${SPLUNK_TOKEN}, and replaces them with the actual environment variable’s value.
This can be done with tools like envsubst (Linux), or with simple scripts in bash, Python, Node.js, etc.
For example, with envsubst you can do:
envsubst < splunk.template.yaml > splunk.yaml
Here, splunk.template.yaml contains placeholders, and the command outputs a new splunk.yaml with the real token substituted.
Deploy the final YAML with the real values
Your application reads the processed YAML file with actual secrets in place, without ever storing the token directly in source control.
Please refer to the documentation for examples
Feature / File | Syntax | Description |
---|---|---|
YAML-style environmentalized value | {{abc.def}} |
This syntax replaces the Policy Studio environmentalization feature. The values are populated from the values.yaml file. |
YAML-style environment selector | {{env "XYZ"}} |
This syntax is allowed everywhere, and it replaces the older style ${environment.XYZ} . The values.yaml file must exist for this syntax to work. Evaluated by API Gateway at load time (rather than runtime) using system environment variables, which means that you are warned about missing system environment variables sooner. |
Legacy environment selector | ${environment.XYZ} |
Only supported for fields that support selectors at runtime. Evaluated by API Gateway at runtime using system environment variables. This can be replaced by the {{env "XYZ"}} syntax. |
envSettings.properties | ${env.xyz} |
Evaluated by API Gateway at load time, using envSettings.props content specific to an instance. These settings are instance-specific as opposed to environment-specific. |
system.properties | ${system.xyz} |
Evaluated by API Gateway at load time, using system.properties file content. |
KPS | ${kps.TableXYZ[some value].field} |
Evaluated at runtime, using the configured Key Properties Store. |
Hi @rawvarun ,
Try below steps:
1. Create a Template YAML File
This file contains a placeholder for the environment variable.
File: splunk.template.yaml
splunk:
hec_token: ${SPLUNK_TOKEN}
hec_url: https://splunk-instance:8088/services/collector
2. Define the Environment Variable
In Adobe Cloud Manager:
Go to Cloud Manager UI => your Pipeline => Edit Variables
Add a variable:
- Name: SPLUNK_TOKEN
- Value: your actual HEC token
- Mark it as secret (this keeps it hidden and secure)
3. Replace Placeholders During Build
In your Cloud Manager pipeline, you can add a custom script step using a shell script to perform substitution.
Script: replace-vars.sh
#!/bin/sh
# Replace environment variables in YAML template
envsubst < splunk.template.yaml > splunk.yaml
Ensure this script is executable:
chmod +x replace-vars.sh
./replace-vars.sh
This file now contains real, secure values injected at runtime, and never stores secrets in Git:
splunk:
hec_token: abc123-real-token
hec_url: https://splunk-instance:8088/services/collector
Regards,
Amit
Views
Replies
Total Likes
Hi @rawvarun
The key is defining the Environment Variable and marking the scope for "all" services. Then using the syntax like this: ${{MY_VAR}}
Hope this helps
what will be the syntax for host which is not secret environment variable?
Views
Replies
Total Likes
@rawvarun Just checking in — were you able to resolve your issue?
We’d love to hear how things worked out. If the suggestions above helped, marking a response as correct can guide others with similar questions. And if you found another solution, feel free to share it — your insights could really benefit the community. Thanks again for being part of the conversation!
Views
Replies
Total Likes
yes, issue is solved now.
@rawvarun Glad to hear it worked for you! Could you please share how you resolved it? If it was solved through another user’s comment, kindly mark that as the correct answer.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies