Supported Configurations
The following table offers a comprehensive list of such configurations with links to dedicated documentation describing its distinct configuration syntax and other information.
| Type | YAML kind Value | Description |
|---|---|---|
| Traffic Filter Rules, including WAF | CDN | Declare rules to block malicious traffic |
| Request Transformations | CDN | Declare rules to transform the shape of the traffic request |
| Response Transformations | CDN | Declare rules to transform the shape of the response for a given request |
| Server-side Redirects | CDN | Declare 301/302-style server-side redirects |
| Origin Selectors | CDN | Declare rules to route traffic to different backends, including non-Adobe applications |
| CDN error pages | CDN | Override the default error page if AEM origin cannot be reached, referencing the location of self-hosted static content in the configuration file |
| CDN Purge | CDN | Declare the Purge API keys used to purge the CDN |
| Customer-managed CDN HTTP token | CDN | Declare the value of the X-AEM-Edge-Key needed to call the Adobe CDN from a Customer CDN |
| Basic authentication | CDN | Declare the usernames and passwords for a basic auth dialog protecting certain URLs. |
| Version Purge Maintenance Task | MaintenanceTasks | Optimize the AEM repository by declaring rules around when content versions should be purged |
| Audit log Purge Maintenance Task | MaintenanceTasks | Optimize the AEM audit log for increased performance by declaring rules around when logs should be purged |
| Log forwarding | LogForwarding | Configure the endpoints and credentials for forwarding logs to various destinations, including Azure Blob Storage, Datadog, HTTPS, Elasticsearch, Splunk |
| Registering a Client ID | API | Scope Adobe Developer Console API projects to a specific AEM environments by registering the client ID. This is needed for usage of OpenAPI-based APIs that require authentication |
Creating and Managing Config Pipelines
For information on how to create and configure pipelines, see CI/CD Pipelines.
When creating a config pipeline in Cloud Manager, be sure to select a Targeted Deployment rather than Full Stack Code when configuring the pipeline.
As noted earlier, configuration for RDEs is deployed using command line tooling rather than a pipeline.
Common Syntax
Each configuration file begins with properties resembling the following example snippet:
kind: "LogForwarding"
version: "1"
metadata:
envTypes: ["dev"]
| Property | Description | Default |
|---|---|---|
kind | A string that determines which type of configuration, such as log forwarding, traffic filter rules, or request transformations | Required, no default |
version | A string representing the schema version | Required, no default |
envTypes | This array of strings is a child property of the metadata node. Possible values are dev, stage, prod, or any combination, and it determines for which environment types the configuration will be processed. For example, if the array only includes dev, the configuration will not be loaded on stage or prod environments, even if the configuration is deployed there. | All environment types (dev, stage, prod) |
You can use the yq utility to validate locally the YAML formatting of your configuration file (for example, yq cdn.yaml).
Folder Structure
A folder named /config or similar should be at the top of the tree, with one more YAML files somewhere in a tree below it.
For example:
/config
cdn.yaml
or
/config
/dev
cdn.yaml
The folder names and filenames below /config are arbitrary. The YAML file, however, must include a valid kind property value.
Typically, configurations are deployed to all environments. If all the property values are identical for each environment, a single YAML file will suffice. However, it is common for property values to differ between environments, for example while testing a lower environment.
The following sections illustrate some strategies for structuring your files.
A Single Config File for All Environments
The file structure will resemble the following:
/config
cdn.yaml
logForwarding.yaml
Use this structure when the same configuration is sufficient for all environments and for all types of configuration (CDN, log forwarding, and so on). In this scenario, the envTypes array property would include all environment types.
kind: "cdn"
version: "1"
metadata:
envTypes: ["dev", "stage", "prod"]
Using secret-type environment variables, it is possible for secret properties to vary per environment, as illustrated by the ${{SPLUNK_TOKEN}} reference
kind: "LogForwarding"
version: "1"
metadata:
envTypes: ["dev"]
data:
splunk:
default:
enabled: true
host: "splunk-host.example.com"
token: "${{SPLUNK_TOKEN}}"
index: "AEMaaCS"
A Separate File Per Environment Type
The file structure will resemble the following:
/config
cdn-dev.yaml
cdn-stage.yaml
cdn-prod.yaml
logForwarding-dev.yaml
logForwarding-stage.yaml
logForwarding-prod.yaml
Use this structure when there may be differences in property values. In the files, one would expect the envTypes array value to correspond with the suffix, for examplecdn-dev.yaml and logForwarding-dev.yaml with a value of ["dev"], cdn-stage.yaml and logForwarding-stage.yaml with a value of ["stage"], and so on.
A Folder Per Environment
In this strategy, there is a separate config folder per environment, with a separate pipeline declared in Cloud Manager for each.
This approach is particularly useful if you have multiple dev environments, where each has unique property values.
The file structure will resemble the following:
/config/dev1
cdn.yaml
logForwarding.yaml
/config/dev2
cdn.yaml
logForwarding.yaml
/config/prod
cdn.yaml
logForwarding.yaml
A variation of this approach is to maintain a separate branch per environment.