Add extension for unsetting env vars in helm chart script
In the deployment of our cluster we need to customize the context.xml.tmpl configuration by adding a new resource for the connection to an external database.
The password should be put inside this configuration and the only option available is to put it in clear text, which is not a viable solution for our security team. In fact all our passwords are stored inside a vault and they are deployed as secrets into our cluster.
We have noticed that if we inject them as environment variable then we are able to use them as .Env.VARIABLE_NAME, but the problem is that storing a password as the environment variable is NOT a secure solution. The problem is that this environment variable is never unset after its replacement in the context.xml file, which is not a recommendable approach from a security point of view (refer to NIST SP 800‑190 standard).
Our example: we have injected in the pod the env variable: SECRET_DB2_CUSTOMDBPASSWORD from a Kubernetes secret.
In the deployment of our cluster we need to customize the context.xml.tmpl configuration by adding a new resource for the connection to an external database.
The password should be put inside this configuration and the only option available is to put it in clear text, which is not a viable solution for our security team. In fact all our passwords are stored inside a vault and they are deployed as secrets into our cluster.
We have noticed that if we inject them as environment variable then we are able to use them as .Env.VARIABLE_NAME, but the problem is that storing a password as the environment variable is NOT a secure solution. The problem is that this environment variable is never unset after its replacement in the context.xml file, which is not a recommendable approach from a security point of view (refer to NIST SP 800‑190 standard).
Our example: we have injected in the pod the env variable: SECRET_DB2_CUSTOMDBPASSWORD from a Kubernetes secret.
<?xml version='1.0' encoding='utf-8'?>
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Manager pathname="" />
<Resource name="jdbc/PegaRULES"
auth="Container"
type="javax.sql.DataSource"
driverClassName="{{ .Env.JDBC_CLASS }}"
url="{{ .Env.JDBC_URL }}"
username="{{ .Env.SECRET_DB_USERNAME }}"
password="{{ .Env.SECRET_DB_PASSWORD }}"
maxTotal="{{ .Env.JDBC_MAX_ACTIVE }}"
minIdle="{{ .Env.JDBC_MIN_IDLE }}"
maxIdle="{{ .Env.JDBC_MAX_IDLE }}"
maxWaitMillis="{{ .Env.JDBC_MAX_WAIT }}"
initialSize="{{ .Env.JDBC_INITIAL_SIZE }}"
connectionProperties="{{ .Env.JDBC_CONNECTION_PROPERTIES }};{{ .Env.JDBC_TIMEOUT_PROPERTIES }}"
timeBetweenEvictionRunsMillis="30000"
minEvictableIdleTimeMillis="60000"
/>
<Resource name="jdbc/PegaRULESLongRW"
auth="Container"
type="javax.sql.DataSource"
driverClassName="{{ .Env.JDBC_CLASS }}"
url="{{- if .Env.JDBC_RW_URL -}}{{ .Env.JDBC_RW_URL }}{{- else -}}{{ .Env.JDBC_URL }}{{- end -}}"
username="{{ .Env.SECRET_DB_USERNAME }}"
password="{{ .Env.SECRET_DB_PASSWORD }}"
maxTotal="{{ .Env.JDBC_MAX_ACTIVE }}"
minIdle="{{ .Env.JDBC_MIN_IDLE }}"
maxIdle="{{ .Env.JDBC_MAX_IDLE }}"
maxWaitMillis="{{ .Env.JDBC_MAX_WAIT }}"
initialSize="{{ .Env.JDBC_INITIAL_SIZE }}"
connectionProperties="{{ .Env.JDBC_CONNECTION_PROPERTIES }};{{ .Env.JDBC_TIMEOUT_PROPERTIES_RW }}"
timeBetweenEvictionRunsMillis="30000"
minEvictableIdleTimeMillis="60000"
/>
<Resource name="jdbc/MYCUSTOMDB"
auth="Container"
type="javax.sql.DataSource"
driverClassName="com.ibm.db2.jcc.DB2Driver"
url="db2url.com"
username="username"
password="{{ .Env.SECRET_DB2_CUSTOMDBPASSWORD }}"
maxTotal="100"
maxIdle="30"
maxWaitMillis="100000"
/>
{{ if and .Env.JDBC_RO_URL .Env.DB_RO_USERNAME .Env.DB_RO_PASSWORD }}
<Resource name="jdbc/PegaRULESReadOnly"
auth="Container"
type="javax.sql.DataSource"
driverClassName="{{ .Env.JDBC_CLASS }}"
url="{{ .Env.JDBC_RO_URL }}"
username="{{ .Env.DB_RO_USERNAME }}"
password="{{ .Env.DB_RO_PASSWORD }}"
maxTotal="{{ .Env.JDBC_MAX_ACTIVE }}"
minIdle="{{ default .Env.JDBC_RO_MIN_IDLE .Env.JDBC_MIN_IDLE }}"
maxIdle="{{ .Env.JDBC_MAX_IDLE }}"
maxWaitMillis="{{ .Env.JDBC_MAX_WAIT }}"
initialSize="{{ default .Env.JDBC_RO_INITIAL_SIZE .Env.JDBC_INITIAL_SIZE }}"
connectionProperties="{{ .Env.JDBC_CONNECTION_PROPERTIES }};{{ .Env.JDBC_TIMEOUT_PROPERTIES_RO }}"
timeBetweenEvictionRunsMillis="30000"
minEvictableIdleTimeMillis="60000"
/>
<Environment name="prconfig/database/databases/PegaRULES/dataSourceReadOnly" value="java:comp/env/jdbc/PegaRULESReadOnly" type="java.lang.String" />
<Environment name="prconfig/database/databases/PegaDATA/dataSourceReadOnly" value="java:comp/env/jdbc/PegaRULESReadOnly" type="java.lang.String" />
{{ if .Env.CUSTOMERDATA_SCHEMA }}
<Environment name="prconfig/database/databases/CustomerData/dataSourceReadOnly" value="java:comp/env/jdbc/PegaRULESReadOnly" type="java.lang.String" />
{{ end }}
{{ end }}
<Environment name="url/initialization/explicittempdir" value="path" type="java.lang.String"/>
<Environment name="prconfig/database/databases/PegaRULES/defaultSchema" value="{{ .Env.RULES_SCHEMA }}" type="java.lang.String" />
<Environment name="prconfig/database/databases/PegaDATA/defaultSchema" value="{{ .Env.DATA_SCHEMA }}" type="java.lang.String" />
{{ if .Env.CUSTOMERDATA_SCHEMA }}
<Environment name="prconfig/database/databases/CustomerData/defaultSchema" value="{{ .Env.CUSTOMERDATA_SCHEMA }}" type="java.lang.String" />
{{ else }}
<Environment name="prconfig/database/databases/CustomerData/defaultSchema" value="{{ .Env.DATA_SCHEMA }}" type="java.lang.String" />
{{ end }}
<Environment name="prconfig/initialization/persistrequestor" value="OnTimeout" type="java.lang.String" />
{{ if .Env.REQUESTOR_PASSIVATION_TIMEOUT }}
<Environment name="prconfig/timeout/browser" value="{{ .Env.REQUESTOR_PASSIVATION_TIMEOUT }}" type="java.lang.String" />
{{ end }}
<Environment name="prconfig/circuitbreaker/startInOpenMode/default" value="{{ default .Env.CIRCUIT_BREAKER_OPEN_MODE false }}" type="java.lang.String" />
{{ if .Env.CONTEXT_XML_SNIPPET }}
{{ .Env.CONTEXT_XML_SNIPPET }}
{{ end }}
</Context>
So we have seen that in the docker-entrypoint.sh script of the Pega pods, you are taking care of removing all the sensible environmet variable after creating the context.xml file.
Would it possible to put in the pega helm chart an extension point to extend the list of environment variables unset at the end of the docker-entrypoint.sh script?
HCA Healthcare
US
You’ve got two paths. Either add a tiny “extra unset” knob to the chart, or avoid envs in the runtime container entirely by rendering the file in an initContainer. Both keep the password out of the long-lived process, which is the real goal.
If you want the quick chart tweak: add a Helm value like extraUnsetEnvVars: [SECRET_DB2_CUSTOMDBPASSWORD, SECRET_DB_PASSWORD]. Pass it to the pod as EXTRA_UNSET_ENV_VARS (comma-separated). In docker-entrypoint.sh, after you render context.xml and before you exec Tomcat/Java, loop over that list and unset each var. Result: the app process never inherits those secrets.
If you want the cleaner model: move templating to an initContainer. Mount the template via ConfigMap, inject the secret as env only in the init, run gomplate to /work/context.xml, then mount that file into the main container from an emptyDir (ideally medium: Memory). The init dies, its env goes away, and the runtime container never had those vars.
Either way, lock file perms (chmod 600), don’t log template expansion, and keep the unset strictly before the final exec.