Some notes about access controls

Author: peterdeme

docs/integrations/source-control/azure-devops.md

@@ -83,6 +83,11 @@ In order for Spacelift to be notified of any changes made in your repositories,
 
 You'll need the **Webhook secret** and the **Webhook endpoint** in the next step.
 
+!!! note
+    If the integration is Space-level, you'll need to have **admin** access to the integration Space to be able to see the sensitive details such as the webhook secret. For the default integration, you'll need to be a **root** Space admin.
+
+    Space **readers** will only be able to see the name, description, and labels of the integration.
+
 For each Azure DevOps project you want to use with this integration, you now have to go into its **Project settings -> Service hooks -> Create subscription**. Within the services list choose **Web Hooks** and click **Next**.
 
 ![Creating a Webhook integration in Azure DevOps](../../assets/screenshots/azureWebhooks1.gif)

docs/integrations/source-control/github.md

@@ -190,10 +190,15 @@ The rest of the process is exactly the same as with [creating a GitHub-backed st
 
 ## Access controls
 
-### By Space-level integrations (recommended)
+### Space-level integrations
 
 If you're using Space-level integrations, you can use the [Spaces](../../concepts/spaces/README.md) to control the access of your GitHub integrations. For example, if you have a Space called `Rideshare`, you can create a GitHub integration in that Space, and that can only be attached to those stacks and modules that are in the same Space (or [inherit](../../concepts/spaces/access-control.md#inheritance) permissions through a parent Space).
 
+#### Integration details visibility
+
+Only Space **admins** will be able to see the webhook URLs and secrets of Space-level integrations. Space **readers** will only be able to see the name, description, and labels of the integration.
+The details of default integrations are visible to **root** Space admins.
+
 ### Legacy method
 
 You can reuse GitHub's native teams as well. If you're using GitHub as your identity provider (which is the default), upon login, Spacelift uses GitHub API to determine organization membership level and team membership within an organization and persists it in the session token which is valid for one hour. Based on that you can set up [login policies](../../concepts/policy/login-policy.md) to determine who can log in to your Spacelift account, and [stack access policies](../../concepts/policy/stack-access-policy.md) that can grant an appropriate level of access to individual [Stacks](../../concepts/stack/README.md).

docs/integrations/source-control/gitlab.md

@@ -43,27 +43,14 @@ Once you've created your personal API token, please pass it - along with the ser
 
 ![](<../../assets/screenshots/Gitlab_set_up_button.png>)
 
-Congrats, you've just linked your GitLab account to Spacelift. You should be taken to the integration settings page where you can retrieve the webhook data - secret and endpoint - which you will need to [integrate Spacelift stacks with GitLab projects](gitlab.md#using-gitlab-with-stacks-and-modules). Don't worry, this data will be accessible again to Spacelift admins, so there's no need to persist it separately:
-
-![](<../../assets/screenshots/Gitlab_3dots.png>)
-<p align="center"><img src="../../assets/screenshots/Gitlab_details.png"></p>
-
 !!! warning
     Unlike GitHub credentials which are specific to an organization rather than an individual, the GitLab integration uses personal credentials, which makes it more fragile in situations where an individual leaves the organization and deletes the access token.
 
     Thus, it may be a good idea to create "virtual" (machine) users in GitLab as a source of more stable credentials. Note however that this is a general concern, not one specific to Spacelift.
 
-## Using GitLab with stacks and modules
-
-If your Spacelift account is integrated with GitLab, the stack or module creation and editing forms will show a dropdown from which you can choose the VCS integration to use. GitLab will always come first, assuming that you've integrated it with Spacelift for a good reason:
-
-![](../../assets/screenshots/Gitlab_create_stack.png)
-
-The rest of the process is exactly the same as with [creating a GitHub-backed stack](../../concepts/stack/creating-a-stack.md#integrate-vcs) or module, so we won't be going into further details.
-
 ### Setting up Webhooks
 
-An important thing though is that for every GitLab project that's being used by a Spacelift project (stack or module), you will need to set up a webhook to notify Spacelift about the project changes. You can find yout **webhook endpoint** and **webhook secret** after clicking the 3 dots next to the integration name on the VCS providers page, and then clicking **See details**.
+For every GitLab project that's being used by a Spacelift project (stack or module), you will need to set up a webhook to notify Spacelift about the project changes. You can find yout **webhook endpoint** and **webhook secret** after clicking the 3 dots next to the integration name on the VCS providers page, and then clicking **See details**.
 
 !!! note
     Space-level integrations will be listed to users with **read** access to the integration Space. Integration details however contain sensitive information (such as webhook secret) so they are only visible to those with **admin** access. On the other hand, default integrations are visible to all users of the account, but only **root** Space admins can see the details of them.
@@ -81,6 +68,14 @@ If that sounds like hassle (it sure does to us), you can do the same thing autom
 
 Regardless of whether you've created it manually or programmatically, once your project webhook is set up, your GitLab-powered stack or module is ready to use.
 
+### Using GitLab with stacks and modules
+
+If your Spacelift account is integrated with GitLab, the stack or module creation and editing forms will show an option to use GitLab as the source of code:
+
+![](../../assets/screenshots/Gitlab_create_stack.png)
+
+The rest of the process is exactly the same as with [creating a GitHub-backed stack](../../concepts/stack/creating-a-stack.md#integrate-vcs) or module, so we won't be going into further details.
+
 ### Namespaces
 
 When utilizing the Terraform provider to provision Spacelift Stacks for GitLab, you are required to specify a `namespace`.