Onboarding a Cluster

Connect Cluster allows you to get the cluster's deployment configuration for deploying and managing the cert-orchestrator from AppViewX KUBE+.
Generating a deployment configuration for the cluster involves initiating the generation of deployment templates or configuration steps. KUBE+ allows DevOps teams or cluster administrators multiple ways to onboard Kubernetes clusters into your inventory, catering to different environments and operational needs. Choose the method that best suits your setup:
  • Generic Onboarding – A universal deployment template for onboarding clusters across any Kubernetes vendor.
  • Marketplace [AWS EKS Addon] – A certified AWS Marketplace integration to seamlessly onboard Amazon EKS clusters via KUBE+ EKS Add-on.
  • Agentless [Cloud Account] (Coming Soon) – Discover and onboard clusters directly via cloud accounts without installing an agent.

Prerequisites

The cert-orchestrator runs as a container workload on the same Kubernetes infrastructure that hosts the workloads that need certificates.
To begin the deployment process, the following prerequisites must be met and verified:
  • Cluster Running Kubernetes version 1.22 and above; OpenShift version 4.10, 4.11 or 4.12.
  • Docker version 20.x installed and running as the container runtime.
  • Containerd running if the cluster does not support docker runtime.
  • Access to either an on-premise AppViewX KUBE+ instance or a subscribed AppViewX SaaS instance.
  • Helm and kubectl packages installed in the Kubernetes cluster.
  • In the case of a bastion host, the bastion host should be connected to the cluster.
  • Access to the helm and docker image repositories.
Note: Contact AppViewX support to obtain the steps to pull the images and charts from the Docker and Helm Repository.

Generic Onboarding

This method generates a common deployment template that can be applied across multiple Kubernetes vendors, making it a flexible choice for organizations with a diverse cluster landscape
  • Easy onboarding: - Enables DevOps team to generate a common deployment template for onboarding multiple clusters.
  • Advanced onboarding - Enables individual cluster administrators to generate cluster specific deployment configuration.

Onboarding a Cluster - Easy Method

Deploy and manage cert-orchestrator on multiple Kubernetes clusters using a common deployment configuration.

The common deployment template enables the DevOps team to generate a generic command that can be executed at multiple clusters where these commands just need Cluster Name and Vendor name to be changed accordingly while executed in the respective clusters.

A credential will be generated with a default user group associated to the OOB role and resource which is downloadable as a YAML and the object type is a Kubernetes secret. The credential can be changed by editing the cluster once it's successfully managed in the inventory.

Additionally, the common deployment configuration enables default services, including discovery of certificates and provisioning of certificates from the Kubernetes cluster. Administrator can modify the services after managing the cluster in the cluster inventory.

If the on-boarding policy is enabled, new clusters will be onboarded with automated policy and PKI configuration. To configure on-boarding policy, follow the Configuring Policy Settings steps.

To obtain the common deployment template for Kubernetes cluster:

  1. Go to menu > KUBE+ > INVENTORY > Cluster Inventory.
  2. Click Connect Cluster on the menu bar.
  3. On the Onboard Cluster popup window, select Get Started under Generic Onboarding.
  4. Select Get Started under Easy Onboarding.
  5. On the Cluster Easy Onboard page, enter values in the form fields to generate the deployment/installation command. Details on the mapping of each field are provided in the table below:
    Table 1. Generating Helm Command - Fields and Description Table
    Field Description
    Cluster Details
    Enter Cluster Name* Enter a unique cluster name in the format of FQDN. Example: my-cluster.net.
    Vendor* Select the K8s vendor where the cert orchestrator is deployed from the dropdown list. The options are:
    • EKS

    • AKS

    • GKE

    • OpenShift

    • Self-Managed

    *: Mandatory fields

  6. Click Generate Installation Command to get the Helm command in the Commands field.
    Note:
    • To see the commands in the full screen view, click the (Expand) icon.
    • To copy the command, click (Copy) icon.
  7. Click Download Credentials to download the credentials of your AppViewX environment. Once deployed in the cluster, this credentials enables connectivity between the Kubernetes cluster and AppViewX environment from the cert-orchestrator deployed in the Kubernetes cluster.
    Note:
    • The downloaded credential creates a default OAuth svc account in AppViewX named kube-svc-account with a client ID and client secret.

    • The kube-svc-account is linked to a default user group named kube-svc-usergroup, which, in turn, is associated with the OOB kube-cert-orchestrator role and super access resource.

    • The downloaded credential includes the connectivity URL (APPVIEWX_ENV_URL), serving as the AppViewX login URL.

      You can also configure additional URLs by adding them as a comma-separated list in APPVIEWX_ENV_ALTERNATE_URLS="". For example, APPVIEWX_ENV_ALTERNATE_URLS="https://mycc1,https://mycc2"

      If the primary URL becomes unreachable or does not respond, cert-orchestrator will automatically switch to one of the configured alternate URLs.

    • After successful onboarding and managing the cluster in the cluster inventory, the user or admin with access to the inventory can edit the cluster.

Onboarding a Cluster - Advanced

Deploy and manage cert-orchestrator on Kubernetes clusters by customizing installation commands and choosing specific services.

The advanced onboarding enables the DevOps team/cluster administrators to generate a specific install command that can be executed at the clusters, administrators or DevOps team can modify the namespace, connectivity URL and KUBE+ services to be deployed in the cluster.

To obtain cert-orchestrator deployment configuration for the respective Kubernetes cluster:

  1. Go to menu > KUBE+ > Inventory > Cluster Inventory.
  2. Click Connect Cluster on the menu bar.
  3. Select Get Started under Advanced Onboarding.
  4. On the Cluster Easy Onboard page, enter values in the form fields to generate the deployment/installation command. Details on the mapping of each field are provided in the table below:
    Table 2. Generating Helm Command - Fields and Description Table
    Field Description
    Cluster and Connectivity Details
    Enter Cluster Name* Enter a unique cluster name in the format of FQDN. Example: my-cluster.net.
    Vendor* Select the K8s vendor where the cert orchestrator is deployed from the dropdown list. The options are:
    • EKS

    • AKS

    • GKE

    • OpenShift

    • Self-Managed

    Connect To* Select one of the following options to establish a connection between the cert-orchestrator and AppViewX across different AppViewX deployment scenarios:
    • AppViewX URL - For on-prem deployment, select this option.

    • Cloud Connector URL - For cloud SaaS deployment, select this option.

    URL* Enter the URL based on the Connect To type (onprem/cloud connector).
    Credential Type* Select one of the following credential types for integrating the cert-orchestrator with AppViewX:
    • Basic Authentication

    • OAuth2.0

    Username* This option is applicable for the Basic Authentication of the Credential Type and will auto populate the list of users from the user inventory. Select the required user to be used for authentication.
    Note: In this mode, only users created within the AppViewX database or on boarded via AAA (LDAP, RADIUS, TACACS) are supported. SSO credentials cannot be used for API authentication. It is recommended to use OAuth 2.0 for authentication instead.
    Crypto Mesh Details
    Namespace* Enter the Namespace where the cert-orchestrator is to be deployed. It is recommended to install in the crypto-mesh namespace.
    Features* Select the list of feature gates to be enabled/disabled in the cert-orchestrator deployment configuration for the cluster.
    Certification Group* Select the certificate group to onboard certificates:
    • Auto Create Group - This option enables Auto creation of Certificate Groups in AppViewX with the Group Name as the Namespace Name.

    • Use Existing - This option allows you to choose the existing certificate group. If you choose this option, select a group from the Select Group dropdown menu. .

    Enable Private Key Discovery* Set the value to “True”, if you want to discover the private keys from the Kubernetes secrets.
  5. Click Generate Installation Command to get the Helm command in the Commands field.
    Note:
    • To see the commands in the full screen view, click the (Expand) icon.
    • To copy the command, click (Copy) icon.
  6. Click Finish.
    Execute the copied installation commands sequentially on your Kubernetes cluster where the cert orchestrator is to be deployed.
    Note:
    • Upon clicking Finish, the deployment generated for the cluster will not appear in the cluster inventory until the cert-orchestrator is successfully deployed within the cluster.
    • If a connection required from the cluster to AppViewX via a proxy, you can set the proxy environment variables in a ConfigMap or Secret:
      • Using a ConfigMap: If you want to use a ConfigMap to specify proxy settings, you can pass the --set certOrchestrator.envConfigMapName=myconfig flag in the Helm command.
        Sample ConfigMap:
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: myconfig
          namespace: crypto-mesh
        data:
          http_proxy: "http://MY_PROXY:MY_PROXY_IP"
          https_proxy: "http://MY_PROXY:MY_PROXY_IP"
          #  no_proxy: "svc,local"
      • Using a Secret: If you prefer to use a Secret (especially if the proxy credentials need to be stored securely), you can pass the --set certOrchestrator.envSecretName=mysecret flag in the Helm command.
        Sample secret:
        apiVersion: v1
        		kind: Secret
        		metadata:
        		  name: proxy-config
        		  namespace: default
        		type: Opaque
        		data:
        		  http_proxy: aHR0cDovLzEyNy4wLjAuMTo4MDgw  # Base64 encoded value of "<http://127.0.0.1:8080>"
        		  https_proxy: aHR0cHM6Ly8xMjcuMC4wLjE6ODA4MA==  # Base64 encoded value of "<https://127.0.0.1:8080>"
        		  no_proxy: MTI3LjAuMC4xLCxsb2NhbGhvc3Q=  # Base64 encoded value of "127.0.0.1,localhost"

To verify if the cert-orchestrator is deployed and functioning as expected, execute the following command:

kubectl get pods --all -n crypto-mesh
Note: The initial status of the cert-orchestrator pod will be in 1/2 running state and the state will be changed to 2/2 upon approval/moving the cluster to managed state in the Cluster inventory.
  • Expected status is for the pods to be in running status with 1/2 state.

  • In case of any issues or logs to be collected or verified, execute kubectl logs -f <cert-orchestrator-podname> -n crypto-mesh.

  • Ensure to review the deployment prerequisites for ephemeral volume if the Ephemeral Volume use case is selected.

Deployment Prerequisites for Ephemeral Volume Feature Gate

Enabling the feature gate Provision Certificates to Ephemeral Volumes for certificate provisioning into pod volumes will require the activation of a CSI driver feature within the cluster where the cert orchestrator is deployed.

To enable the CSI provider:

  1. Add the CSI provider helm repository to the Kubernetes cluster.
    helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts
  2. Install the CSI provider drive in the Kubernetes cluster.
    helm install csi secretsstore-csi-driver/secrets-store-csi-driver --namespace crypto-mesh --set syncSecret.enabled=true --set enableSecretRotation=true --set rotationPollInterval=5m
    Note:
    • The value of RotationPollInterval can be configured to set the time interval at which the CSI driver makes a call to appviewx-csi-provider for synchronizing the certificate content from secret to pod volume.
    • If the CSI provider driver already existed prior to the installation of the crypto mesh, you can skip this step.
    • For CSI feature, in case of any issues or logs to be collected or verified execute kubectl logs -f <appviewx-csi-provider-podname> -n crypto-mesh.

OpenShift Security Permissions

For deploying the AppViewX CSI feature in OpenShift environments, the following elevated privileges are required. To execute the prerequisites, Contact OpenShift Administrator.

  1. After deploying the appviewx-csi-provider in an OpenShift cluster, patch the DaemonSet for the AppViewX CSI Provider to run with a privileged security context.kubectl patch daemonset appviewx-csi-provider \--type='json' \-patch='[{"op": "add", "path": "/spec/template/spec/containers/0/securityContext", "value": {"privileged": true} }]'.
  2. Add the security account for the Secret Store CSI Driver and AppViewX CSI Provider to the privileged security context constraint. To obtain the name of the service account associated with the AppViewX CSI provider, run the command oc get sa -n crypto-mesh, and copy the relevant name to be used in the command below: oc adm policy add-scc-to-user privileged system:serviceaccount:crypto-mesh:secrets-store-csi-driver oc adm policy add-scc-to-user privileged system:serviceaccount:crypto-mesh:<replace with service account name>.
  3. Give additional access to the application for retrieving secrets with the AppViewX CSI Provider. Create a SecurityContextConstraint to allowHostDirVolumePlugin and allowHostPorts for the service account of the application.
    cat > application-scc.yaml << EOF
    apiVersion: security.openshift.io/v1
    kind: SecurityContextConstraints
    metadata:
     name: appviewx-csi-provider
    allowPrivilegedContainer: false
    allowHostDirVolumePlugin: true
    allowHostNetwork: true
    allowHostPorts: true
    allowHostIPC: false
    allowHostPID: false
    readOnlyRootFilesystem: false
    defaultAddCapabilities:
    - SYS_ADMIN
    runAsUser:
     type: RunAsAny
    seLinuxContext:
     type: RunAsAny
    fsGroup:
     type: RunAsAny
    users:
    - system:serviceaccount:crypto-mesh:<replace with service account name>
    EOF
    Kubectl apply -f application-scc.yaml

Marketplace [AWS EKS Addon]

The EKS Addon is an AWS Marketplace integration that allows seamless onboarding of Amazon EKS clusters using KUBE+ EKS Add-on. This method ensures compliance with AWS’s certified deployment process.

For detailed step-by-step instructions, refer to KUBE+ as an EKS Addon - AWS Marketplace.