[meta] Improve credential storage strategy and production readiness
>>> [!note] Migrated issue
<!-- Drupal.org comment -->
<!-- Migrated from issue #3559854. -->
Reported by: [mxr576](https://www.drupal.org/user/315522)
>>>
<h3 id="summary-problem-motivation">Problem/Motivation</h3>
<p>
The amazee.ai AI Provider module currently stores environment-specific credentials and connection details across three configuration entities by default: <code>ai_provider_amazeeio.settings</code>, <code>key.key.amazeeio_ai</code>, and <code>key.key.amazeeio_ai_database</code>.<br>
This approach is not production ready because configuration is both stored in the active database by default and typically exported to version control, which increases the risk of credential leakage through database dumps as well as configuration exports.
</p>
<p>
In addition, the current Amazee AI trial experience appears to prioritize convenience and rapid onboarding over robust credential management, which may be acceptable for local demos and try-out but is not clearly separated from production-ready usage patterns.<br>
There is no coherent, documented strategy in the provider module that describes how credentials and environment-specific information should be stored, rotated, and overridden across environments (local, staging, production).
</p>
<p>
Two documentation and quick-fix issues were opened to mitigate some of the immediate risks: <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/ai_provider_amazeeio/issues/3559845" title="Status: Closed (fixed)">#3559845: Ignore environment-specific credentials in configuration for amazee.ai AI Provider</a></span> (Config Ignore integration) and <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/ai_provider_amazeeio/issues/3559849" title="Status: Active">#3559849: Document secure credential configuration for amazee.ai AI Provider</a></span> (documentation updates for secure configuration in non-demo environments).<br>
These issues improve the situation but do not fully address the underlying credential storage model, the trial vs. production separation, or long-term expectations for secure deployments.
</p>
<h4 id="summary-steps-reproduce">Steps to reproduce</h4>
<ol>
<li>Install <code>ai_provider_amazeeio</code> and follow the current setup and/or trial registration instructions.</li>
<li>Configure Amazee AI connection details and vector database credentials via the provided admin UI at <code>/admin/config/ai/providers/amazeeio</code>.</li>
<li>Inspect the active configuration (for example, using <code>drush cget</code>) and database dumps to see that credentials are stored in configuration entities and thus in the database and config exports.</li>
<li>Optionally copy the database or configuration between environments (for example, using hosting platform tooling) and observe that the target environment may connect to the wrong LLM/vector database using credentials from the source environment.</li>
</ol>
<h3 id="summary-proposed-resolution">Proposed resolution</h3>
<p>
Use this meta issue to design, discuss, and document a comprehensive credential and environment-specific configuration strategy for <code>ai_provider_amazeeio</code>, and to collect all follow-up implementation tasks needed to make the module production ready from a security perspective.<br>
The strategy should explicitly differentiate between a low-friction trial/demo experience and a hardened production setup, including admin UX expectations, storage mechanisms, and recommended deployment practices.
</p>
<h3 id="summary-remaining-tasks">Remaining tasks</h3>
<p>
The goal of this meta issue is to collect and track concrete work items needed to implement an improved credential storage strategy, including quick fixes, documentation, and potential larger refactors.<br>
Below is an initial list of tasks, grouped as already-open quick fixes and potential ideas for future improvements.
</p>
<h4 id="summary-potential-improvements">Potential ideas for further security improvements</h4>
<ul>
<li>
Introduce a clearly separated “trial/demo” experience, for example via a dedicated submodule:
<ul>
<li>Enable simplified credential handling for local/demo use only, with explicit warnings that this mode is not suitable for production.</li>
<li>Ensure administrators are encouraged to migrate to a secure production setup before going live (for example, via status report items or admin notices).</li>
</ul>
</li>
<li>
Define dedicated Key types for Amazee AI and vector database credentials:
<ul>
<li>Key type for Amazee AI API credentials (host, access token).</li>
<li>Key type for vector database credentials (host, database name, username, password).</li>
<li>Allow pluggable key providers so that sites can use environment variables, secret managers, or other storage without changing module code.</li>
<li>Example: <a href="https://www.drupal.org/project/key_apigee">https://www.drupal.org/project/key_apigee</a></li>
</ul>
</li>
<li>
Refine configuration and registration/trial flows to be more credential-storage-aware:
<ul>
<li>Allow administrators to select a key provider and key type within the UI, where appropriate.</li>
<li>Adapt form behavior based on whether the selected key provider accepts user input (for example, read-only providers vs. writable ones).</li>
</ul>
</li>
<li>
Provide a “recommended production setup” checklist in project documentation:
<ul>
<li>Clearly list which credentials and endpoints must not be stored in configuration for production.</li>
<li>Show how to wire settings via <code>settings*.php</code> overrides and/or Key entities for production sites.</li>
</ul>
</li>
<li>
Review and, if needed, adjust the configuration ignore rules and documentation from <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/ai_provider_amazeeio/issues/3559845" title="Status: Closed (fixed)">#3559845: Ignore environment-specific credentials in configuration for amazee.ai AI Provider</a></span> and <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/ai_provider_amazeeio/issues/3559849" title="Status: Active">#3559849: Document secure credential configuration for amazee.ai AI Provider</a></span> once a long-term storage strategy is agreed, so that quick fixes and long-term patterns remain consistent.
</li>
<li>
Add automated tests around the agreed secure patterns:
<ul>
<li>Ensure recommended production setups do not leak credentials via configuration export.</li>
<li>Validate that trial/demo setups are clearly flagged and do not masquerade as production-ready.</li>
</ul>
</li>
</ul>
<h3 id="summary-ui-changes">User interface changes</h3>
<p>
Probably some related to Amazee AI setup administration and trial experience.
</p>
<h3 id="summary-api-changes">API changes</h3>
<p>
N/A
</p>
<h3 id="summary-data-model-changes">Data model changes</h3>
<p>
N/A
</p>
> Related issue: [Issue #3559052](https://www.drupal.org/node/3559052)
issue