Adapt docs for phase 2 of tenant-wide secrets #33
Conversation
|
|
| ### Get Secret: | ||
| The response contains the name, and the creation timestamp of the requested generic secrets. No sensitive information is revealed in the response. | ||
| In the case of a tenant-wide secret, the response also includes a list of all resource groups associated with the tenant and the current replication status of the secret to these resource groups. | ||
|
|
||
| ``` | ||
| # Example response for a tenant-wide secret | ||
| { | ||
| "name": "secret-1", | ||
| "createdAt": "<timestamp>", | ||
| "resourceGroupSecretReplicationStatus":{ | ||
| "rg-id-1" : true, # secret was replicated correctly in this namespace | ||
| "rg-id-2" : false, # secret was not replicated or does not exist in this namespace yet | ||
| } | ||
| } |
There was a problem hiding this comment.
I am assuming the resourceGroupSecretReplicationStatus field is present in the response body only when the headers set the scope to tenant-wide level.
Can this be made explicit here?
| { | ||
| "name": "secret-1", | ||
| "createdAt": "<timestamp>", | ||
| "resourceGroupSecretReplicationStatus":{ |
There was a problem hiding this comment.
Please see above comment on resourceGroupSecretReplicationStatus
| > In order to allow rotation of Tenant-Wide secrets for long-running deployments without restarting the deployment, the following guidelines must be followed: | ||
| > - The deployment MUST mount the Tenant-Wide secret. For more information see [Consume a Generic Secret as a Volume Mount](consume-generic-secrets-in-executions-or-deployments-185a324.md) | ||
| > - The deployment MUST monitor the mounted secret for changes instead of relying on an in-memory copy of the secret read from the mount. | ||
| > - When a Tenant-Wide secret is updated, the tenant is responsible for observing the response of /secrets/{secret-name} endpoint to ensure that the Replicator has successfully updated the secret in all resource groups. |
There was a problem hiding this comment.
Can we mention here that the tenant has to observe the resourceGroupSecretReplicationStatus field to ensure that the replication is successful in all RG namespace? Possibly also add a hyperlink to that page?
| > In order to allow rotation of Tenant-Wide secrets for long-running deployments without restarting the deployment, the following guidelines must be followed: | ||
| > - The deployment MUST mount the Tenant-Wide secret. For more information see [Consume a Generic Secret as a Volume Mount](consume-generic-secrets-in-executions-or-deployments-185a324.md) | ||
| > - The deployment MUST monitor the mounted secret for changes instead of relying on an in-memory copy of the secret read from the mount. | ||
| > - When a Tenant-Wide secret is updated, the tenant is responsible for observing the response of /secrets/{secret-name} endpoint to ensure that the Replicator has successfully updated the secret in all resource groups. |
There was a problem hiding this comment.
Please see comment about adding explanation and hyperlink from the create-a-generic-secret page.
| > ### Note: | ||
| > In order to allow rotation of Tenant-Wide secrets for long-running deployments without restarting the deployment, the following guidelines must be followed: | ||
| > - The deployment MUST mount the Tenant-Wide secret. For more information see [Consume a Generic Secret as a Volume Mount](consume-generic-secrets-in-executions-or-deployments-185a324.md) | ||
| > - The deployment MUST monitor the mounted secret for changes instead of relying on an in-memory copy of the secret read from the mount. | ||
| > - When a Tenant-Wide secret is updated, the tenant is responsible for observing the response of /secrets/{secret-name} endpoint to ensure that the Replicator has successfully updated the secret in all resource groups. |
There was a problem hiding this comment.
This note was already added to this page a few sections above. Are we intentionally repeating it?
No description provided.