diff --git a/docs/docs-content/clusters/cluster-management/backup-restore/backup-restore.md b/docs/docs-content/clusters/cluster-management/backup-restore/backup-restore.md index ee8a318c0a..885eba1b69 100644 --- a/docs/docs-content/clusters/cluster-management/backup-restore/backup-restore.md +++ b/docs/docs-content/clusters/cluster-management/backup-restore/backup-restore.md @@ -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. ::: diff --git a/docs/docs-content/vm-management/rbac/vm-roles-permissions.md b/docs/docs-content/vm-management/rbac/vm-roles-permissions.md index f42aac7b13..e2180a1232 100644 --- a/docs/docs-content/vm-management/rbac/vm-roles-permissions.md +++ b/docs/docs-content/vm-management/rbac/vm-roles-permissions.md @@ -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. diff --git a/docs/docs-content/workspace/adding-a-new-workspace.md b/docs/docs-content/workspace/adding-a-new-workspace.md index bc52c7a142..2beec35090 100644 --- a/docs/docs-content/workspace/adding-a-new-workspace.md +++ b/docs/docs-content/workspace/adding-a-new-workspace.md @@ -1,68 +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
cluster-wide is strongly discouraged. Hence, grant a
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. - - Add the resource quota for the namespaces by specifying CPU and Memory limits (optional). - - 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. + 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. -4. Settings + :::info - - [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. + Unlike Palette RBAC, the users you reference here are Kubernetes user objects in the cluster, not users in your + Palette environment. -Review and finish the configuration and complete the deployment. + ::: + + 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. + + :::info + + 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. diff --git a/docs/docs-content/workspace/workload-features.md b/docs/docs-content/workspace/workload-features.md deleted file mode 100644 index 8ee5dee666..0000000000 --- a/docs/docs-content/workspace/workload-features.md +++ /dev/null @@ -1,545 +0,0 @@ ---- -sidebar_label: "Workspace Management" -title: "The additional features to optimize workspace performance" -description: "How to get unified view of workloads in logically grouped namespaces and clusters" -icon: "" -hide_table_of_contents: false -sidebar_position: 10 -tags: ["workspace"] ---- - -# Manage Palette Workspace - -Palette supports several day 2 operations to manage the end-to-end lifecycle of the Kubernetes clusters through -Workspaces. It also provides several capabilities across new and imported clusters to keep your clusters secure, -compliant, up to date, and perform ongoing management operations like Backup and Restore. Additionally, you can have -visibility into the workloads running inside your cluster and cluster costs. - -The following sections describe these capabilities in detail: - - - - -## Workload Visibility - -Workspace provides visibility into workloads deployed across clusters. - -| **Resource** | **Description availed from Workspace** | -| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Namespaces** | Cluster Specific namespaces with CPU and Memory utilization. | -| **Pods** | Lists all the pods running on a particular namespace with cluster names with the detailed health status, age, and resource utilization of each of them. | -| **Deployments** | All the running deployments specific to clusters belonging to the Workspace with namespace to which these deployments belong, pods details, replicas, and age are enumerated | -| **DaemonSets** | DaemonSet resource utilization is described, with details on namespaces, pods, and age of individual Daemon sets | -| **StatefulSets** | All the active StatefulSets specific to clusters belonging to the Workspace with corresponding namespace, pods details, replicas, and age are enumerated | -| **Jobs** | A Job creates one or more Pods and will continue to retry execution of the Pods until a specified number of them successfully terminate. | -| **CronJobs** | Cron Jobs are regularly scheduled actions or jobs such as backups, report generation, etc. Each of these jobs will recur as scheduled. | -| **RoleBinding** | A role binding grants the permissions defined in a role to a user or set of users. | -| **ClusterRoleBinding** | A Cluster Role binding defines the permissions defined across a cluster. | - - - - - -## Workspace Backup and Restore - -Palette users can create cluster backups from within a workspace (usually consisting of multiple clusters) and restore -them later time as desired. Palette allows granular controls within a workspace for users to perform specific tasks -within the workspace, without having the ability to update workspace details. To provide granular access within a -workspace for specific actions, Palette provides the following two Roles: - -## Workspace Operator - -Users assigned the **Workspace Operator** Role can only perform Backup and Restore actions within the Workspace. - -## Workspace Admin - -A Role that has all administrative permissions and privileges within the Workspace. - -## Create your Workspace Roles - -To create your **Workspace Role**, follow the steps below: - -1. Log in to the Palette Management Console as **Tenant Admin**. - -2. Go to the **Users and Teams** option. - -3. From the listed users, select the user to be assigned with Workspace Roles. Check out the - [Create a User](../user-management/users-and-teams/create-user.md) guide to learn how to create a user. - -4. Select the **Workspace Roles** tab and click **+ New Workspace Role** to create a new role. - -5. Fill the following information into the **Add Roles to User-Name** wizard: - - - Project - - Workspace - - Choose the role from the options: - - Workspace Admin - - Workspace Operator - -6. Confirm the information provided to complete the wizard. - -7. The user set with the Workspace Role can take Workspace-wide Backups and Restores in compliance with their - permissions and privileges. - -Palette leverages the BackUps to the following locations: - -- Amazon Web Services (AWS) S3 Buckets: [Prerequisites](#for-an-amazon-web-services-aws-bucket-as-backup-location), - [Configure your Backup](#configure-your-backup-in-aws-s3) - -- Google Cloud Platform (GCP) Buckets: [Prerequisites](#for-a-google-cloud-platform-gcp-backup-location), - [Configure your Backup](#configure-your-backup-in-gcp-bucket) - -- MinIO S3 Buckets: [Prerequisites](#for-minio-s3-backup), [Configure your Backup](#configure-your-backup-in-minio) - -- Azure Blob: [Prerequisites](#for-azure-blob-backup), - [Configure your Backup](#configure-your-backup-in-azure-azure-blob) - -## Prerequisites - -### For an Amazon Web Services (AWS) Bucket as Backup Location - -- The AWS S3 permissions listed in the next section need to be configured in the AWS account to provision Backup through - Palette. - -- Pre-create a bucket at the AWS or MinIO object-store. - -## For a Google Cloud Platform (GCP) Backup Location - -- GCP service account with a **Storage Admin** role. - -- Pre-create a bucket at the GCP object storage. - -### For MinIO S3 Backup - -- S3 bucket with Read/Write Access - -- A unique access key (username) and corresponding secret key (password) from MinIO Console. - -- Service provider certificate (Optional) - -### For Azure Blob Backup - -- An active Azure cloud account with the following pieces of information noted down: - - - Tenant Id - - Client Id - - Subscription Id - - Client Secret created - -- An - [Azure storage account](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-create?tabs=azure-portal) - created with the following information to be noted down for Palette use: - - - Storage Name: Custom name given to the Azure storage created. - - Stock-keeping unit - -- A container to be created in the Azure Storage account - -## Backup Locations - -AWS Simple Cloud Storage (S3) and other S3 compliant object stores such as MinIO and GCP Buckets are currently supported -as backup locations. These locations can be configured and managed under the **Project** > **Settings** option and can -be selected as a backup location, while backing up any cluster in the project. - -### Configure your Backup in AWS S3 - -The following details are required to configure a backup location in AWS: - -1. **Location Name** - Name of your choice. - -2. **Location Provider** - AWS (This is currently the only choice on the UI. Choose this option when backing up to AWS - S3 or any S3 compliance object store). - -3. **Certificate** - Required for MinIO. - -4. **S3 Bucket** - S3 bucket name must be pre-created on the object-store. - -5. **Configuration** - region=\{region-name},s3ForcePathStyle=\{true/false},s3Url=\{S3 URL}. S3 URL need not be provided - for AWS S3. - -6. **Account Information** - Details of the account which hosts the S3 bucket to be specified as Credentials or STS. - - - Credentials - Provide access key and secret key. - - STS - Provide the ARN and External ID of the IAM role that has permission to perform all S3 operations. The STS - role provided in the backup location should have a trust set up with the account used to launch the cluster itself - and should have the permission to assume the role. - -7. Palette mandates the AWS S3 Permissions while users use the static role to provision worker nodes. - - #### AWS S3 Permissions - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "ec2:DescribeVolumes", - "ec2:DescribeSnapshots", - "ec2:CreateTags", - "ec2:CreateVolume", - "ec2:CreateSnapshot", - "ec2:DeleteSnapshot" - ], - "Resource": "*" - }, - { - "Effect": "Allow", - "Action": [ - "s3:GetObject", - "s3:DeleteObject", - "s3:PutObject", - "s3:AbortMultipartUpload", - "s3:ListMultipartUploadParts" - ], - "Resource": ["arn:aws:s3:::BUCKET-NAME/*"] - }, - { - "Effect": "Allow", - "Action": ["s3:ListBucket"], - "Resource": ["arn:aws:s3:::BUCKET-NAME"] - } - ] - } - ``` - - #### Trust Setup Example - - ```json - { - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam::141912899XX99:root" - }, - "Action": "sts:AssumeRole", - "Condition": {} - } - ] - } - ``` - -### Configure your Backup in GCP Bucket - -These locations can be configured and managed from the **Settings** option under **Project** and can be selected as a -backup location while backing up any cluster in the project. - -The following details are required to configure a backup location in GCP: - -1. **Location Name** - Name of your choice. - -2. **Location Provider** - Google Cloud (Choose this option when backing up to the GCP bucket object store). - -3. **Bucket** - The name of the bucket name pre-created on the object store. - -4. **JSON Credentials** - For external authentication of the GCP storage. - -### Configure your Backup in MinIO - -The following details are required to configure a backup location in AWS: - -1. **Location Name**: Name of your choice. - -2. **Location Provider**: Minio - -3. **Certificate**: Optionally required for MinIO. - -4. **S3 Bucket**: S3 bucket name must be pre-created on the MinIO object-store. - -5. **Region**: Region in which the S3 bucket is created. Example: us-east-1 - -6. **S3 URL**: Url of the MinIO object storage console. Example: `http://12.123.234.567:0000` - -7. **Force S3 path style** : To force S3 pathstyle addressing or else the url will be converted to virtual-hosted style - addressing with bucket name appended to the url.This is an optional setting. - -8. **Authenticate** using MinIo access key and secret access key. - -9. Click **Create** to complete the location creation wizard. - -### Configure your Backup in Azure: Azure Blob - -The following details are required to configure a backup location in Azure: - -1. **Location Name**: A custom name for the storage location getting created. - -2. **Location Provider:** Select **Azure** from the drop-down. - -3. **Container Name:** The container created in Azure Storage. - -4. **Storage Name**: Name of the Azure storage created. - -5. **Stock-Keeping Unit**: Information from the Azure storage. - -6. **Resource Group:** Azure Resource Group name - -7. **Tenant ID:** Azure Account Credential. - -8. **Client ID:** Azure Account Credential. - -9. **Subscription ID**: Azure Account Credential. - -10. **Client Secret:** Secret created in the Azure console needs to be validated. - -11. Click **Create** to complete the location creation wizard. - -## Add a Backup Location - -Go to **Project Settings** > **Backup locations** > **Add a New Backup location**. - -## Create a Workspace Backup - -Backups can be scheduled or initiated in an on demand basis, during the workspace creation. The following information is -required for configuring a Workspace Backup, on demand- - -1. **Backup Prefix / Backup Name**: For scheduled backup, a name will be generated internally, add a prefix of our - choice to append with the generated name. For an on demand backup, a name of user choice can be used. - -2. Select the Backup location. - -3. **Backup Schedule** - Create a backup schedule of your choice from the dropdown list, applicable only to scheduled - backups. - -4. **Expiry Date** - Select an expiry date for the backups. The backup will be automatically removed on the expiry date. - -5. **Include all disks** - Optionally, backup persistent disks as part of the backup. - -6. **Include Cluster Resources** - Select or deselect on your choice. - - | On Demand Backup | - | ------------------------------------------------------------------------ | - | Select the **Workspace to Backup** > **Settings** > **Schedule Backups** | - - | Scheduled Backup | - | ----------------------------------------------------------- | - | **Workspace Creation** > **Policies** > **Backup Policies** | - -## Backup Scheduling Options - -Both the cluster and workspace backup support the following scheduling options: - -- Customize your backup for the exact month, day, hour, and minute of the user's choice. -- Every week on Sunday at midnight -- Every two weeks at midnight -- Every month on the 1st at midnight -- Every two months on the 1st at midnight - -## Restore a Backup - -Backups created manually or as part of the schedule are listed under the Backup/Restore page of the cluster. - -1. Restore operation can be initiated by selecting the restore option for a specific backup. - -2. Next, you will be prompted to select a target cluster where you would like the backup to be restored. The progress of - the restore operation can be tracked from the target cluster's Backup/Restore page. - -3. Finally, restore operations can be done to the cluster running on the same project. - -## Restore Your Backup - -To initiate a restore operation: - -1. Log in to the Palette console as the **Project Admin** and go to **Workspaces** page. - -2. Select the **Workspace Name** to be restored. - -3. From the selected Workspace overview, select **Backups** from the top menu. - -4. The Backup option lists all the backups scheduled for the selected Workspace. Towards the name of the backup, click - the meatball (three horizontal dots) button to open the restore wizard. - -5. Click on the **Restore Backup** option to complete the wizard: - - - Choose of the namespaces to be restored - - Three options are available to filter the resources to be restored: - - - **Include Cluster Resources** - To restore all the cluster scoped resources. - - **Preserve Node Ports** - To preserve ports for node port service running in the cluster. - - **Restore PVs** - To restore the persistent volumes. - -
- - :::tip - - Check **Include Cluster Resource** and **Restore PVs** options together. - - ::: - -6. Make the appropriate choice of resources as per user requirements to complete the wizard. - - - - - -## Workspace Quota - -Palette enables the users to limit resource usage within the workspace optionally. The Quota is specified in terms of -the maximum CPU and memory. Therefore, the resource utilization within the namespace should be below the Quota allocated -across all the clusters. - -## To set your Resource Quota: - -1. During [Step: 3 Associate Namespaces](./adding-a-new-workspace.md#create-your-workspace) of Namespace creation, - **Workspace Quota** can be set by giving the **Maximum CPU** and **Maximum Memory**. Then, all the clusters launched - within the Namespace can use the set Quota. - -2. Namespace Quota can be set for an already deployed workspace as: - `Workspace Settings -> Namespaces -> Workspace Quota` - -### Workspace Quota Notes: - -- The quota allocated to the workspace scope is split across all the namespaces under that workspace per their resource - requirements. - -- The palette allows quotas to be allocated to individual namespaces under a specific workspace. In that case, - individual clusters belonging to that namespace can utilize the quota per their resource requirements. When a - namespace is allocated with a quota, all the clusters belonging to that namespace get allocated with that resource - quota individually. - - **Example**: If Namespace palette-ns belongs to two (2) clusters, p1 and p2, and palette-ns is allocated a quota of 1 - CPU and 1 Gb memory, each of p1 and p2 gets allocated 1 CPU and 1 GB memory individually. - -- Palette allows quota to be allocated to individual clusters under a specific workspace. In that case, the allocated - quota should not exceed the namespace quota. - -- To set an unlimited quota, set the quota value as -1. - - If -1 is set as the quota for a cluster, then we cannot set a quota for the workspace to which the cluster belongs. - - If -1 is set as the quota for a Workspace, then we cannot set a quota for the clusters belonging that Workspace. - - - - -## Regex for Namespaces - -Palette leverages Regex Pattern matching 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. - -## Use Cases - -1. A Regex pattern that start and end with " / ", will select all the workspace names matching the given Regex pattern. - - **Example:** `/^palette-ns/` - -2. A Regex pattern that starts with `negation symbol(~)`, will select all the namespaces that _does not match_ with the - regex expression given. - - **Example:** `~/^(kube|cluster|capi|jet|cert)[-].+/` - - :::info - - No spaces to be added between the `~` operator and the `expression`. - - ::: - - - - - -## Workspace Role Binding - -Workspace Role Binding is a Project scope operation. There are two available options for setting up Roll Binding for a -Workspace: - -- **Cluster** to create a RoleBinding with cluster-wide scope (ClusterRoleBinding). - -- **Namespaces** to create a RoleBinding within namespaces scope (RoleBinding). - -Palette users can choose role creation based on their resource requirements. - -## Configure cluster role bindings - -- Login to Palette as Project admin and select the Workspace to which the Role Binding need to configured. - -- Select Settings -> Cluster - -- Select the clusters from the workspace to Role Bind. - -- Click on “Add new binding” to open the “Add Cluster Role Binding” wizard. Fill in the following details: - - - Role Name: Define a custom role name to identify the cluster role - - Subjects: Subjects are a group of users, services, or teams using the Kubernetes API. It defines the operations a - user, service, or a team can perform. There are three types of subjects: - - Subject Type: - - Users: These are global and meant for humans or processes living outside the cluster. - - Groups: Set of users. - - Service Accounts: Kubernetes uses service accounts to authenticate and authorize requests by pods to the - Kubernetes API server. These are namespaced and meant for intra-cluster processes running inside pods. - - Subject Name: Custom name to identify a subject. A single RoleBinding can have multiple subjects. - -- “Confirm” the information to complete the creation of the ClusterRoleBinding. - -## Configure role bindings: Namespace Scope - -Users can now allocate CPU and Memory [quotas](#workspace-quota) for each **namespace** at the cluster level. - -- Login to Palette as Project admin and select the Workspace to which the Role Binding need to be configured. - -- Select Cluster Settings -> Namespace. - -- Create a namespace with a custom name and add it to the list of the namespace by clicking on “add to the list”. - -- [Allocate resources](workload-features.md#workspace-quota) to the created namespace (CPU and Memory). - -- Click on “Add new binding” to open the “Add ClusterRoleBinding” wizard. Fill in the following details: - - - Namespace: Select the namespace from the drop-down Menu. The list will display the namespaces created during the - previous step. - - Role Type: Select the role type from the drop-down. Either Role or Cluster Role. - - :::info - - A RoleBinding may reference any Role in the same namespace. Alternatively, a RoleBinding can reference a ClusterRole - and bind that ClusterRole to the namespace of the RoleBinding. For example, if you want to bind a ClusterRole to all - the namespaces in your cluster, you use a ClusterRoleBinding. - - ::: - -- Role Name: Define a custom role name to identify the cluster role - -- Subjects: Subjects are a group of users, services, or teams using the Kubernetes API. It defines the operations a - user, service, or group can perform. There are three types of subjects: - - - Subject Type: - - Users: These are global, and meant for humans or processes living outside the cluster. - - Groups: Set of users. - - Service Accounts: Kubernetes uses service accounts to authenticate and authorize requests by pods to the - Kubernetes API server. These are name spaced and meant for intra-cluster processes running inside pods. - - Subject Name: Custom name to identify a subject. A single RoleBinding can have multiple subjects. - -- “Confirm” the information to complete the creation of the RoleBinding. - - - - - -## Restricted Container Images - -Palette users can restrict a few container images from getting deployed into a specific Namespace. This helps the -tenants from accidentally installing a delisted or unwanted container to that specific namespace. - -## Restrict container images to a workspace - -To restrict a container image for a particular namespace within the workspace: - -1. During [Step: 4 Settings](adding-a-new-workspace.md#create-your-workspace) of workspace creation, select the - **Container Images** tab from the left ribbon. - -2. Click on **+ Add New Container Image** and provide the **Namespace** and **Restricted Images**. Multiple images can - be restricted within a namespace by separating them with commas. - -## Restrict container images to a deployed workspace - -The user can add a list of restricted images to an already deployed workspace as: - -1. **Workspace Settings** > **Container Images** - -2. Click on **Add New Container Image** and provide the **Namespace** and **Restricted Images**. Multiple images can be - restricted within a Namespace by separating them with commas. - - - diff --git a/docs/docs-content/workspace/workspace-mgmt/backup-restore.md b/docs/docs-content/workspace/workspace-mgmt/backup-restore.md new file mode 100644 index 0000000000..831b70a61b --- /dev/null +++ b/docs/docs-content/workspace/workspace-mgmt/backup-restore.md @@ -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. + + +- 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 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 as your CSI layer on a cluster deployed to a MAAS environment. These labels ensure that the 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. diff --git a/docs/docs-content/workspace/workspace-mgmt/configure-rbac.md b/docs/docs-content/workspace/workspace-mgmt/configure-rbac.md new file mode 100644 index 0000000000..46bea51dd4 --- /dev/null +++ b/docs/docs-content/workspace/workspace-mgmt/configure-rbac.md @@ -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. diff --git a/docs/docs-content/workspace/workspace-mgmt/delete-workspace.md b/docs/docs-content/workspace/workspace-mgmt/delete-workspace.md new file mode 100644 index 0000000000..0c54bb959c --- /dev/null +++ b/docs/docs-content/workspace/workspace-mgmt/delete-workspace.md @@ -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. diff --git a/docs/docs-content/workspace/workspace-mgmt/resource-mgmt.md b/docs/docs-content/workspace/workspace-mgmt/resource-mgmt.md new file mode 100644 index 0000000000..a74247e7b6 --- /dev/null +++ b/docs/docs-content/workspace/workspace-mgmt/resource-mgmt.md @@ -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 + ``` diff --git a/docs/docs-content/workspace/workspace-mgmt/restrict-images.md b/docs/docs-content/workspace/workspace-mgmt/restrict-images.md new file mode 100644 index 0000000000..e41a4c0726 --- /dev/null +++ b/docs/docs-content/workspace/workspace-mgmt/restrict-images.md @@ -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. diff --git a/docs/docs-content/workspace/workspace-mgmt/workspace-mgmt.md b/docs/docs-content/workspace/workspace-mgmt/workspace-mgmt.md new file mode 100644 index 0000000000..d125b4105d --- /dev/null +++ b/docs/docs-content/workspace/workspace-mgmt/workspace-mgmt.md @@ -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) diff --git a/docs/docs-content/workspace/workspace.md b/docs/docs-content/workspace/workspace.md index 9ec346057c..19ca5edee8 100644 --- a/docs/docs-content/workspace/workspace.md +++ b/docs/docs-content/workspace/workspace.md @@ -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)