Merge pull request #907 from run-ai/doc-fixes-generic

fixes

Author: yarongol

docs/Researcher/cli-reference/runai-submit-dist-mpi.md

@@ -341,7 +341,7 @@ You can start an unattended mpi training Job of name dist1, based on Project *te
 #### --node-pools `<string>`
 
 > Instructs the scheduler to run this workload using specific set of nodes which are part of a [Node Pool](../../Researcher/scheduling/the-runai-scheduler.md#). You can specify one or more node pools to form a prioritized list of node pools that the scheduler will use to find one node pool that can provide the workload's specification. To use this feature your Administrator will need to label nodes as explained here: [Limit a Workload to a Specific Node Group](../../admin/researcher-setup/limit-to-node-group.md) or use existing node labels, then create a node-pool and assign the label to the node-pool.
-> This flag can be used in conjunction with node-type and Project-based affinity. In this case, the flag is used to refine the list of allowable node groups set from a node-pool. For more information see: [Working with Projects](../../admin/admin-ui-setup/).
+> This flag can be used in conjunction with node-type and Project-based affinity. In this case, the flag is used to refine the list of allowable node groups set from a node-pool. For more information see: [Working with Projects](../../admin/aiinitiatives/org/projects.md).
 
 #### --node-type `<string>`
 

docs/admin/admin-ui-setup/admin-ui-users.md

@@ -11,7 +11,7 @@ date: 2023-Dec-28
 The Run:ai UI allows you to manage all of the users in the Run:ai platform. There are two types of users, **local** users and **SSO** users. Local users are users that are created and managed in the Run:ai platform and SSO users are authorized to use the Run:ai platform using an identity provider. All users are assigned levels of access to all aspects of the UI including submitting jobs on the cluster.
 
 !!! Tip
-    It is possible to connect the Run:ai UI to the organization's directory and use single sign-on (SSO). This allows you to set Run:ai roles for users and groups from the organizational directory. For further information see [single sign-on configuration](../runai-setup/authentication/sso.md).
+    It is possible to connect the Run:ai UI to the organization's directory and use single sign-on (SSO). This allows you to set Run:ai roles for users and groups from the organizational directory. For further information see [single sign-on configuration](../runai-setup/authentication/authentication-overview.md).
 
 ## Create a User
 

docs/admin/runai-setup/authentication/researcher-authentication.md

@@ -24,7 +24,7 @@ Assign Researchers to Projects:
 
 * Open the Run:ai user interface and navigate to `Users`. Add a Researcher and assign it a `Researcher` role.
 * Navigate to `Projects`. Edit or create a Project. Use the `Access Control` tab to assign the Researcher to the Project.
-* If you are using Single Sign-On, you can also assign _Groups_. For more information see the [Single Sign-On](sso.md) documentation.
+* If you are using Single Sign-On, you can also assign _Groups_. For more information see the [Single Sign-On](authentication-overview.md) documentation.
 
 ## Kubernetes Configuration
 

docs/admin/runai-setup/authentication/sso/openidconnect.md

@@ -18,13 +18,13 @@ Follow the steps below to setup SSO with OpenID Connect.
 ### Adding the identity provider
 
 1. Go to **Tools & Settings** → **General**  
-1. Open the Security section and click **+IDENTITY PROVIDER**  
-1. Select **Custom OpenID Connect**  
-1. Enter the **Discovery URL**, **Client ID**, and **Client Secret**  
-1. Copy the Redirect URL to be used in your identity provider  
-1. Optional: Add the OIDC scopes  
-1. Optional: Enter the user attributes and their value in the identity provider (see the user attributes table below)  
-1. Click **SAVE**  
+2. Open the Security section and click **+IDENTITY PROVIDER**  
+3. Select **Custom OpenID Connect**  
+4. Enter the **Discovery URL**, **Client ID**, and **Client Secret**  
+5. Copy the Redirect URL to be used in your identity provider  
+6. Optional: Add the OIDC scopes  
+7. Optional: Enter the user attributes and their value in the identity provider (see the user attributes table below)  
+8. Click **SAVE**  
    User attributes
 
 | Attribute | Default value in Run:ai | Description |
@@ -40,30 +40,30 @@ Follow the steps below to setup SSO with OpenID Connect.
 ### Testing the setup
 
 1. Log-in to the Run:ai platform as an admin  
-1. Add [Access Rules](../accessrules.md) to an SSO user defined in the IDP  
-1. Open the Run:ai platform in an incognito browser tab  
-1. On the sign-in page click **CONTINUE WITH SSO**  
+2. Add [Access Rules](../accessrules.md) to an SSO user defined in the IDP  
+3. Open the Run:ai platform in an incognito browser tab  
+4. On the sign-in page click **CONTINUE WITH SSO**  
    You are redirected to the identity provider sign in page  
-1. In the identity provider sign-in page, log in with the SSO user who you granted with access rules  
-1. If you are unsuccessful signing-in to the identity provider, follow the Troubleshooting section below
+5. In the identity provider sign-in page, log in with the SSO user who you granted with access rules  
+6. If you are unsuccessful signing-in to the identity provider, follow the Troubleshooting section below
 
 ### Editing the identity provider
 
 You can view the identity provider details and edit its configuration:
 
 1. Go to **Tools & Settings** → **General**  
-1. Open the Security section  
-1. On the identity provider box, click **Edit identity provider**  
-1. You can edit either the **Discovery URL**, **Client ID**, **Client Secret**, **OIDC scopes**, or the **User attributes**
+2. Open the Security section  
+3. On the identity provider box, click **Edit identity provider**  
+4. You can edit either the **Discovery URL**, **Client ID**, **Client Secret**, **OIDC scopes**, or the **User attributes**
 
-   ### Removing the identity provider**
+   ### Removing the identity provider
 
 You can remove the identity provider configuration:
 
 1. Go to **Tools & Settings** → **General**  
-1. Open the Security section  
-1. On the identity provider card, click **Remove identity provider**  
-1. In the dialog, click **REMOVE** to confirm the action
+2. Open the Security section  
+3. On the identity provider card, click **Remove identity provider**  
+4. In the dialog, click **REMOVE** to confirm the action
 
 !!! Note
       To avoid losing access, removing the identity provider must be carried out by a local user.
@@ -80,23 +80,23 @@ If testing the setup was unsuccessful, try the different troubleshooting scenari
       **Mitigation**:
 
       1. Validate either the user or its related group/s are assigned with [access rules](../accessrules.md) 
-      1. Validate groups attribute is available in the configured OIDC Scopes  
-      1. Validate the user’s groups attribute is mapped correctly
+      2. Validate groups attribute is available in the configured OIDC Scopes  
+      3. Validate the user’s groups attribute is mapped correctly
 
       **Advanced:**
 
       1. Open the Chrome DevTools: Right-click on page → Inspect → Console tab  
-      1. Run the following command to retrieve and paste the user’s token: `localStorage.token;`  
-      1. Paste in [https://jwt.io](https://jwt.io/)  
-      1. Under the Payload section validate the values of the user’s attributes
+      2. Run the following command to retrieve and paste the user’s token: `localStorage.token;`  
+      3. Paste in [https://jwt.io](https://jwt.io/)  
+      4. Under the Payload section validate the values of the user’s attributes
 
 ??? "401 - We’re having trouble identifying your account because your email is incorrect or can’t be found."
       **Description:** Authentication failed because email attribute was not found.
 
       **Mitigation**:
 
       1. Validate email attribute is available in the configured OIDC Scopes  
-      1. Validate the user’s email attribute is mapped correctly
+      2. Validate the user’s email attribute is mapped correctly
 
 ??? "Unexpected error when authenticating with identity provider"
 
@@ -121,7 +121,7 @@ If testing the setup was unsuccessful, try the different troubleshooting scenari
       **Mitigation**:
 
       1. Validate that the configured OIDC scope exists in the Identity Provider  
-      1. Validate the configured Client Secret match the Client Secret in the Identity Provider
+      2. Validate the configured Client Secret match the Client Secret in the Identity Provider
 
       **Advanced:**
 

docs/admin/runai-setup/authentication/sso/openshift.md

@@ -18,12 +18,12 @@ Follow the steps below to setup SSO with OpenShift.
 ### Adding the identity provider
 
 1. Go to **Tools & Settings** → **General**  
-1. Open the Security section and click **+IDENTITY PROVIDER**  
-1. Select **OpenShift V4**  
-1. Enter the **Base URL**, Client ID, and **Client Secret** from your OpenShift OAuth client.  
-1. Copy the Redirect URL to be used in your OpenShift OAuth client  
-1. Optional: Enter the user attributes and their value in the identity provider (see the user attributes table below)  
-1. Click **SAVE**  
+2. Open the Security section and click **+IDENTITY PROVIDER**  
+3. Select **OpenShift V4**  
+4. Enter the **Base URL**, Client ID, and **Client Secret** from your OpenShift OAuth client.  
+5. Copy the Redirect URL to be used in your OpenShift OAuth client  
+6. Optional: Enter the user attributes and their value in the identity provider (see the user attributes table below)  
+7. Click **SAVE**  
    User attributes
 
 | Attribute | Default value in Run:ai | Description |
@@ -39,30 +39,30 @@ Follow the steps below to setup SSO with OpenShift.
 ### Testing the setup
 
 1. Open the Run:ai platform as an admin  
-1. Add [Access Rules](../accessrules.md) to an SSO user defined in the IDP  
-1. Open the Run:ai platform in an incognito browser tab  
-1. On the sign-in page click **CONTINUE WITH SSO**  
+2. Add [Access Rules](../accessrules.md) to an SSO user defined in the IDP  
+3. Open the Run:ai platform in an incognito browser tab  
+4. On the sign-in page click **CONTINUE WITH SSO**  
    You are redirected to the OpenShift IDP sign-in page  
-1. In the identity provider sign-in page, log-in with the SSO user who you granted with access rules  
-1. If you are unsuccessful signing-in to the identity provider, follow the Troubleshooting section below
+5. In the identity provider sign-in page, log-in with the SSO user who you granted with access rules  
+6. If you are unsuccessful signing-in to the identity provider, follow the Troubleshooting section below
 
 ## Editing the identity provider
 
 You can view the identity provider details and edit its configuration:
 
 1. Go to **Tools & Settings** → **General**  
-1. Open the Security section  
-1. On the identity provider box, click **Edit identity provider**  
-1. You can edit either the **Base URL**, **Client ID**, **Client Secret**, or the **User attributes**
+2. Open the Security section  
+3. On the identity provider box, click **Edit identity provider**  
+4. You can edit either the **Base URL**, **Client ID**, **Client Secret**, or the **User attributes**
 
 ### Removing the identity provider
 
 You can remove the identity provider configuration:
 
 1. Go to **Tools & Settings** → **General**  
-1. Open the Security section  
-1. On the identity provider card, click **Remove identity provider**  
-1. In the dialog, click **REMOVE** to confirm the action
+2. Open the Security section  
+3. On the identity provider card, click **Remove identity provider**  
+4. In the dialog, click **REMOVE** to confirm the action
 
 !!! Note
     To avoid losing access, removing the identity provider must be carried out by a local user.
@@ -79,23 +79,23 @@ If testing the setup was unsuccessful, try the different troubleshooting scenari
     **Mitigation**:
 
     1. Validate either the user or its related group/s are assigned with [access rules](../accessrules.md)  
-    1. Validate groups attribute is available in the configured OIDC Scopes  
-    1. Validate the user’s groups attribute is mapped correctly
+    2. Validate groups attribute is available in the configured OIDC Scopes  
+    3. Validate the user’s groups attribute is mapped correctly
 
     **Advanced:**
 
     1. Open the Chrome DevTools: Right-click on page → Inspect → Console tab  
-    1. Run the following command to retrieve and copy the user’s token: `localStorage.token;`  
-    1. Paste in [https://jwt.io](https://jwt.io/)  
-    1. Under the Payload section validate the value of the user’s attributes
+    2. Run the following command to retrieve and copy the user’s token: `localStorage.token;`  
+    3. Paste in [https://jwt.io](https://jwt.io/)  
+    4. Under the Payload section validate the value of the user’s attributes
 
 ??? "401 - We’re having trouble identifying your account because your email is incorrect or can’t be found."
     **Description:** Authentication failed because e-mail attribute was not found.
 
     **Mitigation**:
 
     1. Validate email attribute is available in the configured OIDC Scopes  
-    1. Validate the user’s email attribute is mapped correctly
+    2. Validate the user’s email attribute is mapped correctly
 
 ??? "Unexpected error when authenticating with identity provider"
     ![](img/openshift-identityerror.png)
@@ -118,7 +118,7 @@ If testing the setup was unsuccessful, try the different troubleshooting scenari
     **Mitigation**:
 
     1. Validate that the configured OIDC scope exists in the Identity Provider  
-    1. Validate that the configured Client Secret matches the Client Secret value in the OAuthclient Kubernetes object.
+    2. Validate that the configured Client Secret matches the Client Secret value in the OAuthclient Kubernetes object.
 
     **Advanced:**
 

docs/admin/runai-setup/authentication/sso/saml.md

@@ -86,10 +86,10 @@ If testing the setup was unsuccessful, try the different troubleshooting scenari
       **Description**: After trying to log-in, the following message is received in the RunLai log-in page.
       **Mitigation:**
       1. Go to the Tools & Settings menu  
-      1. Click **General**  
-      1. Open the Security section  
-      1. In the identity provider box, check for a "Certificate expired” error  
-      1. If it is expired, update the SAML metadata file to include a valid certificate
+      2. Click **General**  
+      3. Open the Security section  
+      4. In the identity provider box, check for a "Certificate expired” error  
+      5. If it is expired, update the SAML metadata file to include a valid certificate
 
 ??? "401 - We’re having trouble identifying your account because your email is incorrect or can’t be found."
       **Description:** Authentication failed because email attribute was not found.
@@ -105,14 +105,14 @@ If testing the setup was unsuccessful, try the different troubleshooting scenari
       **Mitigation**:
 
       1. Validate either the user or its related group/s are assigned with [access rules](../accessrules.md)  
-      1. Validate the user’s groups attribute is mapped correctly
+      2. Validate the user’s groups attribute is mapped correctly
 
       **Advanced:**
 
       1. Open the Chrome DevTools: Right-click on page → Inspect → Console tab  
-      1. Run the following command to retrieve and paste the user’s token: `localStorage.token;`  
-      1. Paste in [https://jwt.io](https://jwt.io)  
-      1. Under the Payload section validate the values of the user’s attributes
+      2. Run the following command to retrieve and paste the user’s token: `localStorage.token;`  
+      3. Paste in [https://jwt.io](https://jwt.io)  
+      4. Under the Payload section validate the values of the user’s attributes
 
 ### Advanced Troubleshooting
 
@@ -126,15 +126,15 @@ If testing the setup was unsuccessful, try the different troubleshooting scenari
       Validate the SAML Request to ensure the SAML flow works as expected:
 
       1. Go to the Run:ai login screen  
-      1. Open the Chrome Network inspector: Right-click → Inspect on the page → Network tab  
-      1. On the sign-in page click CONTINUE WITH SSO.  
-      1. Once redirected to the Identity Provider, search in the Chrome network inspector for an HTTP request showing the SAML Request. Depending on the IDP url, this would be a request to the IDP domain name. For example, `accounts.google.com/idp?1234`.  
-      1. When found, go to the Payload tab and copy the value of the SAML Request  
-      1. Paste the value into a SAML decoder (e.g. [https://www.samltool.com/decode.php](https://www.samltool.com/decode.php))  
-      1. Validate the request:  
+      2. Open the Chrome Network inspector: Right-click → Inspect on the page → Network tab  
+      3. On the sign-in page click CONTINUE WITH SSO.  
+      4. Once redirected to the Identity Provider, search in the Chrome network inspector for an HTTP request showing the SAML Request. Depending on the IDP url, this would be a request to the IDP domain name. For example, `accounts.google.com/idp?1234`.  
+      5. When found, go to the Payload tab and copy the value of the SAML Request  
+      6. Paste the value into a SAML decoder (e.g. [https://www.samltool.com/decode.php](https://www.samltool.com/decode.php))  
+      7. Validate the request:  
          * The content of the `<saml:Issuer>` tag is the same as `Entity ID` given when adding the identity provider  
          * The content of the `AssertionConsumerServiceURL` is the same as the `Redirect URI` given when adding the identity provider  
-      1. Validate the response:  
+      8. Validate the response:  
          * The user email under the `<saml2:Subject>` tag is the same as the logged-in user  
          * Make sure that under the `<saml2:AttributeStatement>` tag, there is an Attribute named `email` (lowercase). This attribute is mandatory.  
          * If other, optional user attributes (`groups`, `firstName`, `lastName`, `uid`, `gid`) are mapped make sure they also exist under `<saml2:AttributeStatement>` along with their respective values.

docs/admin/runai-setup/config/non-root-containers.md

@@ -60,7 +60,7 @@ A best practice is to store the user identifier (UID) and the group identifier (
 
 To perform this, you must:
 
-* Set up [single sign-on](../authentication/sso.md). Perform the steps for UID/GID integration.
+* Set up [single sign-on](../authentication/authentication-overview.md). Perform the steps for UID/GID integration.
 * Run: `runai login` and enter your credentials
 * Use the flag --run-as-user
 

docs/admin/runai-setup/config/overview.md

@@ -10,7 +10,7 @@ This section provides a list of installation-related articles dealing with a wid
 |---------------------------------------------------------|-----------|
 | [Designating Specific Role Nodes](node-roles.md) | Set one or more designated Run:ai system nodes or limit Run:ai monitoring and scheduling to specific nodes in the cluster. |
 | [Setup Project-based Researcher Access Control](../authentication/researcher-authentication.md) | Enable  Run:ai access control is at the __Project__ level. | 
-| [Single sign-on](../authentication/sso.md) | Integrate with the organization's Identity Provider to provide single sign-on for Run:ai | 
+| [Single sign-on](../authentication/authentication-overview.md) | Integrate with the organization's Identity Provider to provide single sign-on for Run:ai | 
 | [Review Kubernetes Access provided to Run:ai](access-roles.md)     | In Restrictive Kubernetes environments such as when using OpenShift, understand and control what Kubernetes roles are provided to Run:ai | 
 | [External access to Containers](allow-external-access-to-containers.md) | Understand the available options for Researchers to access containers from the outside | 
 | [User Identity in Container](non-root-containers.md) | The identity of the user in the container determines its access to cluster resources. The document explains multiple way on how to propagate the user identity into the container. |