[DOC] - Refine permission scopes for Cloud provider credentials

Preliminary Checks

• This issue is not a question, feature request, RFC, or anything other than a bug report. Please post those things in GitHub Discussions: https://github.com/nebari-dev/nebari/discussions

Summary

Right now, we redirect users to create their cloud credentials following the base docs on each cloud provider; the problem with this approach is that this might, in some cases, expect the user to have prior knowledge about the cloud provider infrastructure and cloud management, which is not always the case.

And while the provider docs do provide users with more than enough permissions to deploy Nebari, those sets of permissions are not restrictive (in the sense of providing access to some APIs or resources that Nebari does not need or use) and do not provide enough granularity when managing different projects or resources.

We need to explore each cloud provider's scopes/roles to create a custom set of permissions while generating Nebari cloud credentials. An example of such a system can be found here under Custom IAM.

This will benefit our in-depth docs in the future if a user requests detailed information on what nebari has access to or how they can adapt those accounts to their use cases or cloud policies.

One advantage of doing this exploration is that we can refine the credentials used by admins when deploying nebari and CI/CD tools when refreshing or deploying the application. This might become in handy in tracking the updated history of the resources using cloud APIs

Steps to Resolve this Issue

This will require the following:

• Exploration of each cloud provider credential and permission system, I can foresee that DO might not give us enough freedom of customization in that regard
• Test with different sets of permissions to refine as much as possible Nebari control over cloud resources and how the user interacts with these.

Start by reviewing the existing base credential guidance for each cloud provider and the linked GCP Custom IAM example. Compare the permission and role systems across the providers, then test candidate permission sets against Nebari's deployment and CI/CD needs. Done means the provider-specific scopes are documented with their limitations and validated against the resources Nebari uses.