Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Version History

« Previous Version 9 Next »

Note

These are only required when the AKS cluster is created externally, and you want to configure it for automated or post-deployment/post upgrade from Kyvos Manager.

No permission is required for AKS new deployments when you select to create a new AKS cluster.

For Existing Kubernetes Cluster

Ensure that you perform the following when using the existing Kubernetes cluster.

  1. Ensure that the Compute Namespace is pre-created.

  2. A Storage Class must be pre-configured.

  3. Assign a dedicated namespace to each Kyvos application.

  4. If using a shared/existing Kubernetes cluster, ensure the user node pool must have the taint-    ComputeWorkerOnly=true:NoSchedule

  5. To configure taints as per your requirement, modify the kyvos-compute-worker-job.yaml.template from KM > Manage Configuration Files and save the changes. Then, navigate to Kyvos and Ecosystem > Compute Cluster and reapply the configuration to make it effective.
    For more details, see the Adding Taints and Configure Tolerations in Kyvos worker pods section.

For Automated Deployment

  • If Authentication and Authorization is set to Microsoft Entra ID authentication with Azure RBAC (AAD is enabled)

    image-20241220-093012.png
    1. No action is required for a dedicated cluster.

    2. For shared cluster, you must have already created namespace and KyvosMI with Azure Kubernetes Service RBAC Admin on the namespace level.

      1. Download kyvos-compute-worker-disk-class.yaml file and execute the kubectl apply –f kyvos-compute-worker-disk-class.yaml command from the user/MI which has Admin privileges on AKS cluster. This is to create storage class. If required, you can update the tags in the file by passing comma-separated values.

Note

This is applicable only with an existing Managed Identity.

  • If Authentication and Authorization is set to Local Accounts with Kubernetes RBAC (AAD is disabled)

    image-20241220-092905.png
    1. No action is required for a dedicated cluster.

    2. For shared cluster, namespace must be already created.

For switching or configuring cluster after deployment

This information mentioned in this section is also applicable for wizard-based deployments.

If you want to use existing Kubernetes

  • If Authentication and Authorization is set to Microsoft Entra ID authentication with Azure RBAC (AAD is enabled)

  1. To configure as a dedicated cluster

    1. Assign Azure Kubernetes Service RBAC Cluster Admin to kyvos MI on AKS.

    2. Assign Virtual Machine Contributor on managed resource group to Kyvos MI.

    3. Storage Blob Data Contributor to AKS Managed Identity on bucket.

  2. To configure as a shared Cluster:

    1. Either namespace should be already created or provide Azure Kubernetes Service RBAC Cluster Admin permission to kyvos MI on AKS.

    2. Download kyvos-compute-worker-disk-class.yaml file and execute the kubectl apply –f kyvos-compute-worker-disk-class.yaml command from the user/MI which has Admin privileges on AKS cluster. This is to create storage class. If required, you can update the tags in the file by passing comma-separated values.

    3. If namespace is already created, then Kyvos Managed Identity must have Azure Kubernetes Service RBAC Admin on namespace and Azure Kubernetes Service Cluster User Role on AKS.

    4. Assign Reader on managed resource group to Kyvos Managed Identity.

    5. Storage Blob Data Contributor to AKS Managed Identity on bucket.

  • If Authentication and Authorization is set to Local Accounts with Kubernetes RBAC (AAD is disabled)

  1. To configure as a dedicated Cluster

    1. Assign Contributor to Kyvos MI on AKS.

    2. Assign Virtual Machine Contributor on managed resource group to Kyvos MI.

    3. Storage Blob Data Contributor to AKS Managed Identity on bucket.

  2. To configure as a shared Cluster

    1. If namespace is already created, then Kyvos MI must have Azure Kubernetes Service Cluster User Role on AKS.

    2. Assign Reader on AKS to Kyvos MI.

    3. Assign Reader on managed resource group to Kyvos MI.

    4. Storage Blob Data Contributor to AKS MI on bucket.

Note

If scaling is enabled in any of the following cases of shared AKS cluster, the following roles must be assigned to Kyvos MI on the AKS cluster.

  1. "Microsoft.ContainerService/managedClusters/agentPools/write"

  2. "Microsoft.ContainerService/managedClusters/agentPools/read"

Enhanced Security

  1. AKS Subnet must be allowed in networking rules of Kyvos storage account.

  2. AKS Subnet must be allowed in networking rules of Kyvos key Vault.

  • No labels