Porter is extensible and supports a couple extension points where you can alter its default behavior. Plugins implement a well-defined interface and can be switched by editing Porter’s configuration file.
Storage plugins let you save Porter’s data to a secure location that has backup capabilities. Porter ships with a default plugin, mongodb-docker, that stores Porter’s data on a local Docker volume. The mongodb-docker plugin is intended only for trying out Porter and is not suitable for use in production. In production, you should set up a mongodb server and use the mongodb storage plugin.
A storage plugin can implement the plugins.StorageProtocol interface to store Porter’s data to a different service. The storage protocol uses the mongodb API so changing the backend to something that doesn’t support mongo queries would be difficult.
Secrets plugins allow you to retrieve secrets from a secret store, and save any sensitive data generated by Porter back to the same secret store. The default secrets plugin is the host plugin, which can resolve secrets from environment variables, files, commands and hard-coded values. It does not support persisting secrets generated by Porter and in production you must configure Porter to use a different secrets plugin such as the Azure plugin or the Hashicorp plugin.
During bundle execution, any parameters or bundle outputs that contains sensitive data are stored into a secret store that is configured by the user. Credentials are never persisted, either to Porter’s database or secret store, and are always retrieved just-in-time before the bundle is run.
A secrets plugin can implement the plugins.SecretsProtocol interface and resolve credentials from remote and ideally more secure locations. For example, the Azure plugin resolves secrets from Azure Key Vault.