Skip to content

Commit

Permalink
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: Workspace refactor (#5064)
Browse files Browse the repository at this point in the history
* docs: start working on the create page

* docs: more workspace refactor work

* docs: progress on workspace refactor

* docs: finish workspace pages

* docs: fix broken lilnk

* docs: remove feature page

* docs: broken link fix

* docs: edit workspaces

* docs: copy edits

* docs: add backup page

* docs: add backup & restore sections

* docs: adjust page order

* docs: add more examples

* docs: modify example

* docs: add restore options

* docs: vale

* Apply suggestions from code review

Co-authored-by: caroldelwing <[email protected]>

* Update docs/docs-content/workspace/workspace-mgmt/delete-workspace.md

* Apply suggestions from code review

Co-authored-by: caroldelwing <[email protected]>

* Apply suggestions from code review

Co-authored-by: caroldelwing <[email protected]>

---------

Co-authored-by: caroldelwing <[email protected]>
lennessyy and caroldelwing committed Dec 20, 2024
1 parent 8341431 commit 0bd7dd1
Showing 11 changed files with 694 additions and 634 deletions.
Original file line number Diff line number Diff line change
@@ -42,8 +42,9 @@ To get started with creating a backup, check out the

:::info

If you are using a workspace, refer to the [Manage Palette Workspace](../../../workspace/workload-features.md) guide to
learn more about backup and restore actions for a workspace.
If you are using a workspace, refer to the
[Manage Palette Workspace](../../../workspace/workspace-mgmt/workspace-mgmt.md) guide to learn more about workspace
backup and restore actions.

:::

5 changes: 1 addition & 4 deletions docs/docs-content/vm-management/rbac/vm-roles-permissions.md
Original file line number Diff line number Diff line change
@@ -37,7 +37,4 @@ to specify bindings to configure granular Role-Based Access Control (RBAC) rules
You can configure namespaces and RBAC from within a cluster or from a Palette workspace that contains a cluster group.
In a cluster group, all RoleBindings must occur at the namespace level. For details, review the
[Cluster RBAC](../../clusters/cluster-management/cluster-rbac.md) and
[workspace RBAC](../../workspace/workspace.md#role-based-access-controlrbac) guides.

Palette leverages Regex Pattern matching so you can select multiple namespaces to apply role bindings. Check out
[Regex for Namespaces](../../workspace/workload-features.md#regex-for-namespaces) to learn more.
[workspace RBAC](../../workspace/workspace-mgmt/configure-rbac.md) guides.
154 changes: 109 additions & 45 deletions docs/docs-content/workspace/adding-a-new-workspace.md
Original file line number Diff line number Diff line change
@@ -1,72 +1,136 @@
---
sidebar_label: "Adding a Workspace"
title: "Adding a workspace"
description: "How to create multi-cluster workspace in Palette"
sidebar_label: "Create a Workspace"
title: "Create a Workspace"
description: "How to create a multi-cluster workspace in Palette."
icon: ""
hide_table_of_contents: false
sidebar_position: 0
tags: ["workspace"]
---

Palette enables multi-cluster management and governance capabilities by introducing Workspaces. This section explains
how a workspace can be created in the Palette console.
Palette enables multi-cluster management and governance capabilities by introducing workspaces. This page teaches you
how to create a workspace in Palette. All workspace settings can be updated after creation.

## Prerequisites

- One or more running workload clusters within the project.
- Cluster must not be imported with read-only mode.
- RBAC should not be set at cluster level but to be included at workspace level.
- Palette Virtual Clusters cannot be part of the workspace.
- One or more active workload clusters within the project where the workspace is to be created. The clusters cannot be
imported in read-only mode. Palette virtual clusters also cannot be part of a workspace.
- You have the permission to create workspaces. For more information, refer to
[Permissions](../user-management/palette-rbac/permissions.md).

## Create Your Workspace

1. Add the Basic Information Provide the basic information for the workspace such as:
1. Log in to [Palette](https://console.spectrocloud.com).

- Unique Name
- Optional Description
- Optional Tag
2. In the **Drop-Down Menu** at the top of the page, choose the project you want to create the workspace in. Workspaces
are always scoped to a project.

2. Associate Clusters
3. On the left **Main Menu**, click **Workspaces**. Then click **New Workspace**.

- Select the clusters to be added to the workspace. (See [New Clusters](../clusters/clusters.md) to learn how to add
a new Cluster.) Palette clusters, as well as brownfield clusters, can be added to your workspace.
4. Provide the basic information for the workspace.

- Configure the Cluster Role Binding (optional). Role bindings can be created on all workspace clusters.
- **Name**: The workspace name must be unique in the project.
- **Description**: An optional description for the workspace.
- **Tag**: Optional tags for the workspace.

- As step 2 of the new Workspace creation, select **Add Cluster Role Binding**.
- Provide the name of the role for which the cluster role binding needs to be created. The role should be
pre-existing or an in-built system role. Palette does not create cluster roles.
- Subjects for the cluster role binding can be groups, users, or service accounts.
When you are finished, click **Next**.

| **Subject Type** | **Subject Name** | **Subject Namespace** |
| ------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **User** | a valid path segment name | NA |
| **Group** | a valid path segment name | NA |
| **Service Account** | a valid path segment name | Granting super-user access to all service accounts <br /> cluster-wide is strongly discouraged. Hence, grant a <br /> role to all service accounts in a namespace. |
5. Choose clusters you want to include in the workspace. A cluster may be included in multiple workspaces. Refer to
[Create a Cluster](../clusters/clusters.md) to learn how to add a new cluster.

3. Associate Namespaces
6. On the **Clusters** page, you can optionally create cluster role bindings. To create a new cluster role binding,
click **Add New Binding**. Enter the name of the cluster role you want to reference in the cluster role binding.

- Enter one or more namespaces that need to be part of the workspace. The combination of workspace and cluster is
unique across workspaces in a project. Palette ensures that all the namespaces are created for all the clusters in
the workspaces, in case they are not pre-existing.
After specifying the role, you need to specify the subject to which the cluster role binding is applied to. Select
the subject type and then enter the name of the subject. The name of the subject must be the same as it is defined in
the cluster.

- Add the resource quota for the namespaces by specifying CPU and Memory limits (optional).
:::info

- Configure the Role Binding (optional). The following information is required for each role binding:
- Select a namespace name or the Regex for namespaces for selecting multiple namespaces.
- Specific name for the role which is pre-existing
- Make the selection of Subjects from the dropdown list (User, Group, or ServiceAccount). For the subject selected,
provide a valid path segment name. For the subject, ServiceAccount select namespace name as granting super-user
access to all service accounts cluster-wide is strongly discouraged due to security concerns.
- Confirm the information provided to complete the configuration of role binding.
Unlike Palette RBAC, the users you reference here are Kubernetes user objects in the cluster, not users in your
Palette environment.

4. Settings
:::

- [Schedule Backups](../clusters/cluster-management/backup-restore/backup-restore.md) - set the backup and restore
policies.
- [Container Image](workload-features.md#restrict-container-images-to-a-workspace) - list out the container images to
be restricted within a Workspace namespace.
While this action will create the same role binding across all the clusters that are part of the workspace, it does
not define the cluster role nor the subject the role is bound to. You need to define the role yourself in each
cluster as well as define the subject the role is bound to. Otherwise, the cluster role binding will not have any
effect.

## Validation
:::info

Review and finish the configuration and complete the deployment.
If the cluster role in each cluster has different permissions, then the subjects that the role is bound to will also
have different permissions across clusters, even though they have the same cluster role binding. The same applies to
namespace-scoped role bindings defined in the next step.

:::

7. Enter the namespaces you want to include in the workspace. If a cluster that is part of your workspace has that
namespace, the namespace and all resources that are scoped within it will be included in the workspace. If any
cluster in the workspace is missing the namespace you entered, the namespace will be created on that cluster.

You must use the names of the namespaces exactly, not regular expressions. The regular expression entries are only
used for creating role bindings in a later step.

8. After selecting the namespaces, you can specify resource limits that the workspace is allowed to consume in the
**Workspace Quota** section. The **Maximum CPU** and **Maximum Memory** allow you to specif the maximum amount of CPU
cores and memory that all resources in the entire workspace are allowed to consume.

9. You may also specify resource limits on specific namespaces.

For example, if you have two clusters, `cluster1` and `cluster2`, and they each have a namespace called `default`. If
you impose a 2 Gi memory limit on the namespace default, then the `default` namespace in both clusters will be able
to consume 2 Gi memory each. For more information about resource quotas, refer to
[Resource Management](./workspace-mgmt/resource-mgmt.md).

You must ensure that the namespaced limits, when added together, do not exceed the total workspace limit you
configured. If you impose a workspace quota of 4 Gi memory for a two-cluster workspace, then a namespace cannot have
more than 2 Gi of memory as its limit, since there are two such namespaces in the workspace and both of them added
together are allowed 4 Gi of memory.

10. On the same **Namsespaces** page, you can optionally configure role bindings. When you configure a role binding for
a namespace, you are configuring the same role binding in that namespace in every cluster. Like in Kubernetes, you
can use either a role or a cluster role in a role binding. Similar to cluster role bindings, this action does not
create the roles or the subject for you. You must ensure that the corresponding role and subject referenced in the
role binding exists in the namespaces you configured.

You can use Regular Expressions (regex) to create role bindings in multiple namespaces that match a certain pattern.
To do so, enter the regex in the namespace field. For example, `/palette-.*/` will match all namespaces that start
with `palette-`. When creating the role binding, you can select the regex as the namespace.

:::info

Regex entries in the **Namespaces** field do not add the namespaces that match the regex to the workspace. You will
not be able to monitor resource usage, impose resource limits, or create backups unless you specifically add a
namespace by its name.

:::

When you are finished, click **Next**.

11. In the **Setting** page, you can schedule backups for select namespaces. These backups are created for each cluster
in the workspace.

Like cluster backups in Palette, restoring a backup requires the source cluster to be available. When you restore a
backup, the namespaces that are backed up are restored to each cluster in the workspace. If you delete a cluster
from the workspace, that cluster's backup will not be restored.

For more information about backups, refer to
[Backup and Restore](../clusters/cluster-management/backup-restore/backup-restore.md).

12. Lastly, you can restrict certain container images from being loaded in the namespaces that are managed by the
workspace. To restrict images from being loaded by resources in a namespace, click **Add New Container Image**.
Select a namespace you want to restrict the image in, and enter the image URLs in a comma-separated list. When you
are done, click **Next**.

13. Review your configurations and click **Finish Configuration** to create the workspace.

## Validate

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project you created the workspace in.

3. On the left **Main Menu**, click **Workspaces**.

4. Confirm the workspace has been created with the right configurations.
545 changes: 0 additions & 545 deletions docs/docs-content/workspace/workload-features.md

This file was deleted.

157 changes: 157 additions & 0 deletions docs/docs-content/workspace/workspace-mgmt/backup-restore.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,157 @@
---
sidebar_label: Backup and Restore
title: Backup and Restore
description: "Learn how to configure backup and restore for your workspaces."
hide_table_of_contents: false
sidebar_position: 30
tags: ["workspace"]
---

Palette allows you to create backups at the workspace-level. A workspace backup may include any or all namespaces
included in the workspace, across every cluster in the workspace. The backup feature for workspaces uses the same
Velero-based approach as regular cluster backups and are subject to the same limitations. For more information, refer to
[Cluster Backup and Restore](../../clusters/cluster-management/backup-restore/backup-restore.md).

The backup files will be stored in a backup location you configure. Each cluster will have its own backup files. When
you delete a workspace, the backup files will not be deleted.

## Create a Workspace Backup

Backing up a workspace creates a backup file for every cluster in your workspace. Each cluster backup file will contain
all Kubernetes objects as well as volumes in the namespaces selected.

### Prerequisites

- You have configured at least one backup location for cluster backups. Refer to
[Add Backup Location using Static Credentials](../../clusters/cluster-management/backup-restore/add-backup-location-static.md).

- You are logged in as a Palette user that has the permission to back up workspaces. For more information, refer to
[Permissions](../../user-management/palette-rbac/permissions.md).

- The clusters in the workspace you want to backup are healthy and available. Unhealthy clusters will not be backed up.

<!-- prettier-ignore -->
- If you want to include volume snapshots in the backup, ensure that your CSI driver supports volume snapshots. For more
information about volume support, review the CSI pack README for your CSI driver in use. Refer to the [Volume Snapshots](../../clusters/cluster-management/backup-restore/backup-restore.md#volume-snapshots) section for more information.

:::warning

Ensure that `manifests.volume-snapshot-class.deletionPolicy` is set to the `Retain` value if you have configured <VersionedLink text="Volume Snapshot Controller" url="/integrations/packs/?pack=volume-snapshot-controller" /> as a layer in your cluster profile. This setting allows volume snapshot content to be retained when volume snapshots are deleted, facilitating backup and restore functionality.

```yaml hideClipboard {5}
volume-snapshot-class:
create: true
name: "spectro-volume-snapshot-class"
driver: ""
deletionPolicy: "Retain"
```
Additionally, you must add the following snippet under the `manifests.volume-snapshot-class` field if you are using <VersionedLink text="Portworx" url="/integrations/packs/?pack=csi-portworx-generic" /> as your CSI layer on a cluster deployed to a MAAS environment. These labels ensure that the <VersionedLink text="Volume Snapshot Controller" url="/integrations/packs/?pack=volume-snapshot-controller" /> pack installs correctly.

```yaml
extraLabels:
pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/audit: privileged
pod-security.kubernetes.io/warn: privileged
```

:::

### Procedure

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Click on the workspace you want to back up.

5. Click **Settings** in the upper-right corner.

6. Click **Schedule backups**.

7. Fill in the following basic information about your scheduled backups.

| Parameter | Description |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Backup prefix | The prefix to your backup file names. |
| Select backup location | Select a location to store your backup files. |
| Backup schedule | Configure a schedule for your backups. |
| Select expiry | The period for which your backup files are kept. Backup files past the expiry date are deleted automatically. |
| Include all disks | Select this checkbox if you want to include all the disks in the backup. |
| Include cluster-wide resources | Cluster wide resources are resources that are not namespaced but are scoped to the whole cluster, such as cluster roles. **Auto** option includes persistent volumes that are linked to claims within the selected namespaces, but exclude other cluster-wide resources. |

8. Enter the namespaces you want to back up.

9. Select the clusters you want to back up.

10. Click **Save Changes**.

The backup process will take some time ranging from 15 minutes to hours depending on the scope of the backup.

### Validate

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Click on the workspace you backed up.

5. Click on the **Backups** tab.

6. Confirm that your backup is in progress or completed.

## Restore a Workspace Backup

Restoring a workspace will restore the selected namespaces in every cluster that is currently in the workspace to the
same state from which the backup was created. The clusters being restored must be healthy and reachable, because the
restore process relies on access to the Kubernetes API. If you have deleted a cluster from the workspace, the deleted
cluster will not be restored.

### Prerequisites

- You have created a backup file for the workspace.

- You are logged in as a Palette user that has the permission to restore workspaces. For more information, refer to
[Permissions](../../user-management/palette-rbac/permissions.md).

- The clusters you want to restore are healthy and available.

### Procedure

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Click on the workspace you want to restore.

5. Click on **Backups** to switch to the backup tab.

6. Click on a backup file you want to restore from.

7. You have the following options for restoring the backup.

| Option | Description |
| ------------------------- | ------------------------------------------------------------------------- |
| Include Cluster Resources | Check the box to restore all the cluster scoped resources. |
| Preserve Node Ports | Check the box to preserve ports for the node port service in the cluster. |
| Restore PVs | Check the box to restore the persistent volumes. |

8. Click **Restore Backup**.

### Validate

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Click on the workspace you restored.

5. Ensure that the result of the restore was successful.
159 changes: 159 additions & 0 deletions docs/docs-content/workspace/workspace-mgmt/configure-rbac.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,159 @@
---
sidebar_label: "Configure RBAC in Workspaces"
title: "Configure RBAC in Workspaces"
description: "Learn how to configure RBAC in workspaces."
hide_table_of_contents: false
sidebar_position: 0
tags: ["workspace", "rbac"]
---

Workspaces extends Kubernetes' native Role-Based Access Control (RBAC) model to allow you to create role bindings and
cluster role bindings at the workspace level, unifying authorization across different clusters. This page teaches you
how to create workspace-level role bindings and cluster role bindings.

RBAC in workspaces is distinct from Palette RBAC. Palette RBAC regulates access to Palette resources such as clusters,
workspaces, and Edge hosts and its subjects are Palette users. Workspace RBAC is an extension of Kubernetes' native RBAC
model. It regulates access to Kubernetes objects in the clusters encompassed by the workspace, and its subjects are
Kubernetes users, groups, and service accounts.

| | Workspace RBAC | Palette RBAC |
| --------------------- | -------------------------------------------------------- | -------------------------------------------------------- |
| Access control domain | Kubernetes API objects in the clusters in the workspace. | Palette resources. |
| Subjects | Kubernetes users, groups, and service accounts. | Palette users and teams. |
| Example resources | ConfigMaps, Secrets, Pods, StatefulSets, etc. | Cluster profiles, clusters, workspaces, Edge hosts, etc. |

Because workspace RBAC is built on top of Kubernetes RBAC, we recommend you becoming familiar with Kubernetes' RBAC
model before using workspace RBAC. For more information about RBAC in Kubernetes, refer to the
[Kubernetes Documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/).

## Create Workspace-Level Role Bindings

By creating a workspace-level role binding, you create role bindings in all clusters in the workspace in the namespaces
you choose. You can also use Regular Expressions (regex) to create role bindings in all namespaces that match the regex.

For example, if you create a role binding that binds the cluster role `podReader` to the service account
`podReaderAccount` in the `default` namespace, every cluster in your workspace will get a role binding that binds the
cluster role `podReader` to the service account `podReaderAccount` in that cluster's `default` namespace.

### Prerequisites

- An existing workspace. Refer to [Create a Workspace](../adding-a-new-workspace.md) to learn how to create a workspace.

- You are logged in as a Palette user that has the permission to modify workspaces. For more information, refer to
[Permissions](../../user-management/palette-rbac/permissions.md).

### Procedure

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Click on the workspace you want to update.

5. In the upper-right corner, click **Settings**. Then click **Namespaces**.

6. If the namespace where you want to include is already in the workspace, skip this step.

At the top of the page, enter the namespace you want to create the role bindings in. Note that doing so will include
the namespace in the workspace and Palette users who have access to this workspace will be able to view its workloads
and resource consumption.

Alternatively, enter a regex that matches the namespaces where you want to create the role binding. Each regex needs
to start and end with a forward slash `/`. For example `/palette-.*/` will match any namespace that starts with
`palette-`. You may also use the negation symbol `~` to select all namespaces that do not match the regex. For
example, `~/palette-.*/` matches everything that does not start with `palette-`.

:::info

Using regex will _not_ include the namespaces that match the regex in the workspace. It will still allow you to
create the role bindings, but the workloads in those namespaces will not be visible, and you cannot backup those
namespaces.

:::

7. Click **Add New Binding**.

8. In the **Namespace** field, select a namespace or the regex. Then enter the **Role type** and **Role name**. As is in
Kubernetes, you can use either a role or a cluster role to create a role binding. If you use a cluster role, the
privilege of the cluster role will still be limited to the namespace where the role binding exists.

:::info

This action only creates the role bindings, but does not create the role or the subject referenced in the role
binding. Kubernetes allows you to create role bindings without creating the role or the subject, but the role binding
will have no effect until it can match with a role and a subject. You must make sure to create the role and the
subject in the namespaces or clusters yourself.

:::

9. In the **Subject** fields, choose the type of the subject and enter the subject name. You can enter as many subjects
as you need.

10. Click **Confirm**.

### Validate

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**. Select your workspace.

4. Switch to the **Role Bindings** tab.

5. Search for entries that starts with **spectro-on-demand-**. Open these entries to confirm that the role bindings bind
the expected role to the expected subject.

## Configure Cluster Role Binding in All Clusters

By creating a workspace-level cluster role binding, you create the same cluster role binding in every cluster in your
workspace.

For example, if you create a cluster role binding that binds the cluster role `podReader` to the service account
`podReaderAccount`, every cluster will get the role binding that binds the cluster role `podReader` to the service
account `podReaderAccount`.

### Prerequisites

- An existing workspace. Refer to [Create a Workspace](../adding-a-new-workspace.md) to learn how to create a workspace.

- You are logged in as a Palette user that has the permission to modify workspaces. For more information, refer to
[Permissions](../../user-management/palette-rbac/permissions.md).

### Procedure

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Click on the workspace you want to update.

5. In the upper-right corner, click **Settings**. Then click **Clusters**.

6. Click **Add New Binding**.

7. In the **Cluster Role name** field, enter the name of the cluster role. In the **Subjects** field, enter the type and
name of the subject. You can enter as many subjects as you need.

As is with role bindings, neither the cluster role nor the subjects referenced need to exist when you create the
cluster role binding. However, you must create them in each cluster. Otherwise, the cluster role binding will have no
effect.

8. Click **Confirm**.

### Validate

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**. Select your workspace.

4. Switch to the **Cluster Role Bindings** tab.

5. Search for entries that start with **spectro-on-demand-**. Open these entries to confirm that the role bindings bind
the expected role to the expected subject.
47 changes: 47 additions & 0 deletions docs/docs-content/workspace/workspace-mgmt/delete-workspace.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
sidebar_label: Delete Workspace
title: Delete Workspace
description: "Learn how to delete a workspace. "
hide_table_of_contents: false
sidebar_position: 40
tags: ["workspace"]
---

This page teaches you how to delete a workspace. Deleting a workspace removes resources in the cluster that you created
using the workspace, such as role bindings, cluster role bindings, and resource quotas. Deleting a workspace does not
delete any of the clusters inside the workspace.

Deleting the workspace will not automatically delete any backup files you created for the workspace.

## Prerequisites

- An existing workspace. Refer to [Create a Workspace](../adding-a-new-workspace.md) to learn how to create a workspace.

- You are logged in as a Palette user that has the permission to delete workspaces. For more information, refer to
[Permissions](../../user-management/palette-rbac/permissions.md).

## Delete a Workspace

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Click on the workspace you want to delete.

5. In the upper-right corner, click **Settings**.

6. Click **Delete Workspace**.

7. Enter the workspace name to confirm the deletion.

## Validate

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Confirm that the workspace has been deleted.
107 changes: 107 additions & 0 deletions docs/docs-content/workspace/workspace-mgmt/resource-mgmt.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,107 @@
---
sidebar_label: "Resource Management"
title: "Resource Management"
description: "Learn how to monitor workload resource consumption and implement resource quotas for your workspace."
hide_table_of_contents: false
sidebar_position: 20
tags: ["workspace", "resource-management"]
---

Workspaces give you a unified view of resource consumption in specified namespaces across all clusters in the workspace.
Additionally, you can implement resource quotas for the workspace as a whole, or for individual namespaces. The resource
quotas are implemented using the native Kubernetes ResourceQuota object. Refer to the
[Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas) to learn more about resource
quotas.

## Monitor Resource Consumption

Workspaces allow you to view the workloads such as pods, deployments, daemon sets, and stateful sets in the namespaces
that comprise the workspace.

In the workspace details page, the landing **Namespaces** tab give you an overview of how much resources are consumed by
each namespace. The **CPU** and **Memory** column display the total CPU and memory consumed by the namespaces with the
same name in the entire workspace.

You can view more workloads by selecting the corresponding tab. For example, select the **Pods** tab if you want to
monitor pod workloads. Each tab will show you the CPU and memory consumption of the corresponding workload in the entire
workspace.

| **Resource** | **Available Information** |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Namespaces** | CPU and memory utilization of the namespace in each cluster. |
| **Pods** | Lists all the pods in a particular namespace with cluster names with detailed health status, age, and resource utilization. |
| **Deployments** | All deployments in the namespaces included in the workspace and their age, pods, and resource utilization. |
| **DaemonSets** | All daemon set in the namespaces included in the workspace and their age, pods, and resource utilization. |
| **StatefulSets** | All the active StatefulSets in the namespaces included in the workspace and their age, pods, replicas, and resource utilization. |
| **Jobs** | All jobs in the namespaces included in the workspace and their status. |
| **CronJobs** | All cron jobs in the namespaces included in the workspace and their status. |
| **RoleBinding** | All role bindings in the namespaces included in the workspace, including the role name and the subject name. |
| **ClusterRoleBinding** | All cluster role bindings in the clusters included in the workspace. |

## Implement Resource Quotas

You can implement resource quotas on an entire workspace or implement them on individual namespaces. Resource quotas are
implemented through Kubernetes' native ResourceQuota object. For more information about resource quotas in Kubernetes,
refer to [Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/resource-quotas/).

### Prerequisites

- An active Palette workspace. Refer to [Create a Workspace](../adding-a-new-workspace.md) to learn how to create one.

- You are logged in as a Palette user that has the permission to modify workspaces. For more information, refer to
[Permissions](../../user-management/palette-rbac/permissions.md).

### Procedure

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Click on the workspace you want to update.

5. Click **Settings** in the upper-right corner.

6. Click **Namespaces**.

7. Under **Workspace Quota**, you can specify the amount of CPU and memory that the entire workspace is allowed to
consume. The default value is 0, which imposes no limit.

8. If you want to limit resource use based on namespaces, enter the desired CPU and memory limit in the **Allocate CPU**
and **Allocate memory** columns next to the namespace entry.

By default, the namespace in each cluster has the same resource limit. You can change this and enter the limit on the
namespace in one particular cluster. You must ensure that resources configured to individual namespaces do not exceed
the workspace quota when added together.

For example, if you have two clusters in the workspace and impose a workspace-level quota of 8 Gi of memory and 8
CPUs, when each instance of the namespace in each cluster is added together, the total memory and CPU quota cannot
exceed 8 Gi of memory and 8 CPUs.

The following resource quota configuration is not allowed for a workspace with 8 Gi of memory and 8 CPUs because the
resource quotas add up to 11 Gi and 11 CPUs.

| | Cluster 1 | Cluster 2 |
| ----------- | ------------ | ------------ |
| Namespace 1 | 4 Gi, 4 CPUs | 4 Gi, 4 CPUs |
| Namespace 2 | 2 Gi, 2 CPU | 1 Gi, 1 CPU |

The following resource quota configuration is allowed because the total quota is 8 Gi and 8 CPUs.

| | Cluster 1 | Cluster 2 |
| ----------- | ------------ | ------------ |
| Namespace 1 | 2 Gi, 2 CPUs | 2 Gi, 2 CPUs |
| Namespace 2 | 3 Gi, 3 CPU | 1 Gi, 1 CPU |

### Validate

1. Connect to a cluster in your workspace using kubectl. For more information, refer to
[Access Cluster with kubectl](../../clusters/cluster-management/palette-webctl.md).

2. Issue the following command to view the resource quotas created for your cluster. Confirm that the corresponding
resource quotas have been created. You may also use the `--namespace` flag to choose a specific namespace to examine.

```shell
kubectl get resourcequota --all-namespaces
```
53 changes: 53 additions & 0 deletions docs/docs-content/workspace/workspace-mgmt/restrict-images.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
---
sidebar_label: Restrict Container Images
title: Restrict Container Images
description: "Learn how to restrict certain images from being used by your workspace"
hide_table_of_contents: false
sidebar_position: 60
tags: ["workspace"]
---

You can specify image URLs in a workspace to restrict access to those images for specific namespaces. Restricted images
cannot be loaded into any cluster in the namespaces you specify.

Access control to images is achieved using Kyverno policies. For more information about Kyverno, refer to
[Kyverno documentation](https://kyverno.io/).

## Prerequisites

- An active Palette workspace. Refer to [Create a Workspace](../adding-a-new-workspace.md) to learn how to create one.

- You are logged in as a Palette user that has the permission to modify workspaces. For more information, refer to
[Permissions](../../user-management/palette-rbac/permissions.md).

## Restrict Container Image

1. Log in to [Palette](https://console.spectrocloud.com).

2. In the **drop-down Menu** at the top of the page, choose the project that has your workspace.

3. On the left **Main Menu**, click **Workspaces**.

4. Click on the workspace you want to delete.

5. In the upper-right corner, click **Settings**.

6. Click **Container Images**.

7. Enter the namespace you want to restrict image access for. Then enter the images by tag, separated by commas.

8. Click **Save Changes**.

## Validate

1. Connect to a cluster in your workspace using kubectl. For more information, refer to
[Access Cluster with kubectl](../../clusters/cluster-management/palette-webctl.md).

2. Issue the following command to view the Kyverno policy used to control image access.

```shell
kubectl describe cpol cluster-policy-palette-system
```

3. Check under `spec.rules.preconditions` and `spec.rules.validate`. Confirm that the matching namespaces have
restricted the container images from loading.
25 changes: 25 additions & 0 deletions docs/docs-content/workspace/workspace-mgmt/workspace-mgmt.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
---
sidebar_label: "Workspace Management"
title: "Workspace Management"
description: "Resources for workspace management."
icon: ""
hide_table_of_contents: false
sidebar_position: 0
tags: ["workspace"]
---

After creating a workspace, you can monitor the workloads and their resource usage in your workspace in Palette. In
addition, you can make changes to the workspace, including adding and removing namespaces role bindings, and resource
quotas.

## Resources

- [Configure RBAC in Workspaces](configure-rbac.md)

- [Resource Management](resource-mgmt.md)

- [Backup and Restore](./backup-restore.md)

- [Restrict Container Images](restrict-images.md)

- [Delete Workspace](./delete-workspace.md)
71 changes: 33 additions & 38 deletions docs/docs-content/workspace/workspace.md
Original file line number Diff line number Diff line change
@@ -8,56 +8,51 @@ sidebar_custom_props:
tags: ["workspace"]
---

Palette extends its multi-cluster management and governance capabilities by introducing **Workspaces**. Workspaces
enable the logical grouping of clusters and namespaces to provide application or team-specific governance and visibility
into workloads, cost, and usage metrics. For example, the application or team workload may be deployed into namespaces
across clusters to achieve High Availability (HA), Disaster Recovery (DR), organization-specific placement policies,
etc. Grouping such namespaces and clusters into a workspace provide central management and governance in a multi-cluster
distributed environment. The following sections describe various aspects of multi-cluster management via workspaces.
A workspace in Palette consists of a group of clusters and namespaces and the resources scoped in those clusters and
namespaces. Using workspaces enables you to provide application or team-specific governance and visibility into
workloads, cost, and usage metrics.

## Namespace Management
For example, the application or team workload may be deployed into namespaces across clusters to achieve High
Availability (HA), Disaster Recovery (DR), or other organization-specific placement policies. Grouping such namespaces
and clusters into a workspace allows centralized management and governance in a multi-cluster distributed environment.

Workspaces automate the creation and deletion of namespaces common to all clusters within the workspace. A workspace can
hold a set of namespaces. Spectro Cloud Palette will periodically reconcile the workspace definition and add/remove
namespaces if required from all clusters part of the workspace.
The following sections describe what Palette workspaces can help you achieve.

## Quota Control
## Namespace and Resource Management

Usage quota in terms of CPU and memory usage limits is specified within the namespaces. Spectro Cloud Palette sets the
specified limits across all the clusters in the namespaces.
Workspaces in Palette automate the creation and management of namespaces across all clusters in the workspace. This
includes:

## Role Based Access Control(RBAC)
- **Namespace Creation**: Creating namespaces across all clusters in your workspace if a cluster does not have a
specified namespace.
- **Resource Quotas**: Defining and enforcing CPU and memory usage limits within namespaces, applied uniformly across
all clusters in the workspace.

Role bindings and cluster role bindings are specified within workspaces. Furthermore, these role bindings and cluster
role bindings are created in every cluster within the workspaces, thus enabling centralized RBAC.
## Centralized Access Control

## Utilization
Workspaces simplify Role-Based Access Control (RBAC) by centralizing management of role bindings and cluster role
bindings. You can specify role bindings and cluster role bindings within the workspace to automatically apply them to
all clusters, ensuring consistent and secure access policies across all clusters in a workspace.

Spectro Cloud Palette reports detailed resource utilization of workloads deployed in all the namespaces in the workspace
across clusters. In addition, the CPU and memory usage trends within the workspace provide valuable insights into the
consumption patterns of an application distributed across clusters.
## Visibility and Insights

## Cost Attribution
Workspaces enhance operational visibility and provide actionable insights

Spectro Cloud Palette computes utilization costs for workloads deployed in all the namespaces that are part of the
workspace across all the clusters based on the detailed resource utilization data. This can be used for internal
charge-back or show-back purposes to determine the cost incurred by an application or team.
- **Workload Visibility**: A centralized workload browser aggregates and displays workloads (pods, deployments, jobs,
stateful sets, etc.) across all namespaces and clusters in the workspace.
- **Resource Utilization**: Detailed reporting on CPU and memory usage trends across clusters to understand consumption
patterns.
- **Cost Attribution**: Calculating costs for workloads based on resource utilization, enabling internal charge-back or
show-back for teams or applications.

## Workload Visibility
## Backup and Disaster Recovery

Workspaces provide a workload browser to view all the workloads such as pods, deployment, jobs, stateful sets, etc.,
deployed in all the namespaces that are part of the workspace across all the clusters. The workload browser aggregates
resources across clusters from relevant namespaces and presents them with centralized visibility.
**Workspace-Based Backup**: Extends cluster-level backups to include namespaces in all clusters within a workspace. For
detailed prerequisites and instructions, refer to the
[Backup and Restore](../clusters/cluster-management/backup-restore/backup-restore.md) page.

## Backup and Restore
## Resources

A workspace-based backup is similar to a cluster backup, with the additional coverage of multiple clusters, should the
workspace include more than one. The prerequisites and detailed instructions to backup and restore clusters are
specified on the [Backup and Restore](../clusters/cluster-management/backup-restore/backup-restore.md) page.
- [Create a Workspace](./adding-a-new-workspace.md)

## Regex for Namespaces

Palette leverages [Regex Pattern matching](workload-features.md#regex-for-namespaces) to select multiple namespaces to
apply Role binding concurrently. When we have many namespaces to be configured for role binding, the user can provide a
Regex pattern matching multiple namespaces instead of giving a single namespace. This will help select all the
namespaces matching the given Regex pattern to be selected together for role binding. >
- [Workspace Management](./workspace-mgmt/workspace-mgmt.md)

0 comments on commit 0bd7dd1

Please sign in to comment.