NGINXaaS: add docs for Secret Manager integration

[valyria257]

Proposed changes

NGINXaaS can now fetch secrets from Secret Manger. This adds
instructions on how to integrate with Secret Manager and use
secrets as certificates for NGINX configurations.

---

This moves the "Identity and access management" page to
be under the "Getting started" section because it no
longer applied to just logging and monitoring. Luckily,
the page's URL is already under getting-started, so that
did not need to change.

This also updated the page's contents to add instructions
to allow fetching secrets from Secret Manager.

Checklist

Before sharing this pull request, I completed the following checklist:

• I read the Contributing guidelines
• My branch adheres to the Git conventions
• My content changes adhere to the F5 NGINX Documentation style guide
• If my changes involve potentially sensitive information¹, I have assessed the possible impact
• I have waited to ensure my changes pass tests, and addressed any discovered issues

Footnotes

1. Potentially sensitive information includes personally identify information (PII), authentication credentials, and live URLs. Refer to the style guide for guidance about placeholder content. ↩

[github-actions]

✅ Deploy Preview will be available once build job completes!

Name	Link
😎 Deploy Preview	https://frontdoor-test-docs.nginx.com/previews/docs/1675/

---

[tstraley]

Suggested change

	To grant access to export metrics to a Google project, `$METRIC_PROJECT_ID` in the [Google Cloud Console](https://console.cloud.google.com/),
	To grant access to export metrics to a Google project, `$METRIC_PROJECT_ID`, in the [Google Cloud Console](https://console.cloud.google.com/), perform the following steps.

[tstraley]

TODO?

[tstraley]

I get what all this is telling me, but I'm worried it's because I know the intent. I'm thinking about the customer here and wondering if we need to be a bit more clear about the use-case and what a user might want to do with this.

Specifically, I keep thinking about the term "certificate" being everywhere, but no mention of "private keys" which are the actual things users need to keep secure..

---

General suggestions:

1. Maybe we want a little more context somewhere in this area about "you can manage your private key material in Google Secret Manager, and F5 NGINXaaS for Google Cloud will securely provide them to your NGINXaaS deployment for use in your NGINX configuration without these secrets leaving Google Cloud"

2. It might help to add a more clear example below since we are specifically illustrating the SSL use-case here, and not generic secrets. eg.

- Add your PEM-encoded private key to a secret in Google Secret Manager
- ... <steps you have about navigating the config UI>
- For example, you may create a file called `/etc/nginx/ssl/server.key` referencing your PEM-encoded private key in Secret Manager, and reference it in your NGINX configuration with `ssl_certificate_key /etc/nginx/ssl/server.key` in the appropriate `server` block.
- Note: there are many ways to manage your public certificates, but one option is to include the PEM certificate data in the same secret as your private key: NGINX supports a single file for both the certificate(s) and key used in the `ssl_certificate` directive.

(I'm just brainstorming here, the wording isn't great, but we can clean this up and make it sound nice with tech writer assistance if you agree that we can add some clarity with these approaches).

[tstraley]

This reads like ssl_certificate or ssl_certificate_key are the only directives that can be used with this (I don't think / hope we don't have any restriction like that).

There are many others that serve the SSL use-case:

• proxy_ssl_certificate_key
• grpc_ssl_certificate_key
• uwsgi_ssl_certificate_key

Maybe to clarify without enumerating everything:

Suggested change

	| File Path | This path can match one or more ssl_certificate or ssl_certificate_key directive file arguments in your NGINX configuration. | The path must be unique within the same deployment. |
	| File Path | The secret will be written to this file path so it can be used with NGINX directives such as ssl_certificate or ssl_certificate_key in your NGINX configuration. | The path must be unique within the configuration. |