ruanweihong-aaa commented on issue #14038:
URL: https://github.com/apache/apisix/issues/14038#issuecomment-6213438822
For this issue, I’d like to propose using temporary placeholders in the
Standalone YAML loader specifically for multiline environment variable values
in SSL certificate and private key fields.
Users could keep the existing syntax:
```yaml
ssls:
- id: example
snis: ["example.com"]
cert: "${{SERVER_CERT}}"
key: "${{SERVER_KEY}}"
#END
```
The environment variables would contain the original multiline PEM content,
without requiring users to escape newlines as literal `\n` sequences.
The proposed flow is:
1. Identify complete variable references at YAML paths such as
`ssls[*].cert` and `ssls[*].key`, rather than matching field names in raw text.
2. If the referenced value contains actual newline characters, store the
original value and insert a temporary placeholder at that location.
3. Continue using the existing substitution logic for other variables.
4. After parsing the YAML, restore the original content only in the
corresponding certificate fields, before subsequent validation and loading.
This would avoid changing the semantics of all multiline variables. Existing
certificate configurations using single-line values with escaped newlines, as
well as other fields using variables to expand YAML sequences, should retain
their current behavior.
I have run an independent experimental script against the stock APISIX
3.19.0 image. The tested cases distinguish SSL fields from similarly named
fields elsewhere, preserve multiline certificate content, and retain the
results of ordinary sequence expansion and literal `\n` certificate
configurations. These tests cover field identification and content restoration
only; real TLS validation and full regression testing are still pending.
Further work would include handling unquoted variable references in
flow-style YAML and configurations generated entirely from environment
variables, along with YAML anchors, aliases, and placeholder collisions. The
scope for certificate arrays and CA fields also needs to be clarified.
Configurations that cannot be reliably identified should retain the existing
loading behavior to avoid introducing new parsing errors.
Given that `$ENV://` already supports loading certificates from environment
variables, would maintainers be open to further developing this approach,
scoped to SSL fields and supporting the existing `${{VAR}}` syntax? Or would
you prefer keeping the current implementation and improving the `$ENV://`
documentation?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
