Change Details

One of the goal of the Alkane PaaS should is to provision secrets securely through Vault. This strategy is especially important for database access, as it allows to ease the maintenance of credentials: the same secret is used to configure both database server and application configuration. As such, the strategy to provision credentials secrets to PHP applications is to generate through Salt a .env or a specific app config file with the relevant credentials, only to be read by the php-fpm pool user. *Why PHP applications don't fetch secret themselves directly?* While applications reading the configuration at startup time and initializing database persistent connections at that moment can query Vault themselves, this is tricky for PHP applications: they need to do that at EACH request. To query Vault at each request would require a fast and full HA cluster, with auto unseal, to avoid to introduce a single point of failure. For example, we want to be able to upgrade Vault frequently, when new versions are released, and to still serve credentials during this upgrade, we need such a cluster. *Note about saas-wordpress role* There is a plan to ease WordPress maintenance to create a SaaS like we did for MediaWiki. Experimental path and config work is ongoing at /srv/wordpress on Ysul. This is not currrently in scope for this change: the saas-wordpress role is currently strictly limited to generate wp-config.php Ref T1828 for .env Ref T1685 for wp-config.php

One of the goal of the Alkane PaaS should is to provision secrets securely through Vault. This strategy is especially important for database access, as it allows to ease the maintenance of credentials: the same secret is used to configure both database server and application configuration. As such, the strategy to provision credentials secrets to PHP applications is to generate through Salt a .env or a specific app config file with the relevant credentials, only to be read by the php-fpm pool user. *Why PHP applications don't fetch secret themselves directly?* While applications reading the configuration at startup time and initializing database persistent connections at that moment can query Vault themselves, this is tricky for PHP applications: they need to do that at EACH request. To query Vault at each request would require a fast and full HA cluster, with auto unseal, to avoid to introduce a single point of failure. For example, we want to be able to upgrade Vault frequently, when new versions are released, and to still serve credentials during this upgrade, we need such a cluster. *Note about saas-wordpress role* There is a plan to ease WordPress maintenance to create a SaaS like we did for MediaWiki. Experimental path and config work is ongoing at /srv/wordpress on Ysul. This is not currently in scope for this change: the saas-wordpress role is currently strictly limited to generate wp-config.php Ref T1828 for .env Ref T1685 for wp-config.php

One of the goal of the Alkane PaaS should is to provision secrets securely through Vault. This strategy is especially important for database access, as it allows to ease the maintenance of credentials: the same secret is used to configure both database server and application configuration. As such, the strategy to provision credentials secrets to PHP applications is to generate through Salt a .env or a specific app config file with the relevant credentials, only to be read by the php-fpm pool user. *Why PHP applications don't fetch secret themselves directly?* While applications reading the configuration at startup time and initializing database persistent connections at that moment can query Vault themselves, this is tricky for PHP applications: they need to do that at EACH request. To query Vault at each request would require a fast and full HA cluster, with auto unseal, to avoid to introduce a single point of failure. For example, we want to be able to upgrade Vault frequently, when new versions are released, and to still serve credentials during this upgrade, we need such a cluster. *Note about saas-wordpress role* There is a plan to ease WordPress maintenance to create a SaaS like we did for MediaWiki. Experimental path and config work is ongoing at /srv/wordpress on Ysul. This is not currrently in scope for this change: the saas-wordpress role is currently strictly limited to generate wp-config.php Ref T1828 for .env Ref T1685 for wp-config.php