Managing the Mesh Inventory

Mesh Inventory displays a list of service mesh onboarded for a cluster. On Mesh Inventory page, you can:

refresh the list, click the (refresh) icon.
go to the pages, click the (navigation) icon.

The mesh inventory list includes the following information:

Table 1. Mesh Inventory - Column and Description Table
Mesh Name	Description
Name	Unique name to identify the mesh configuration for the designated cluster.
Cluster Name	Name of the Cluster for which the service mesh requires external CA signing.
CA Mode	Issuer's CA mode.
Vendor	The vendor name of the service mesh.
Certificate Authority	Certificate Authority to verify the identities of requesting certificates and links them to cryptographic keys by issuing digital certificates.
Created By	Refers to the user who created the mesh.

Onboarding a Mesh

To enable External CA signing for the Service Mesh deployed in your cluster, the Cert-orchestrator running with the Signer component needs to be enabled with a Certificate Authority Setting (CA Setting), a Kubernetes resource that represents the configuration of certificate authorities (CAs) responsible for generating signed certificates through certificate signing requests.

Prerequisites:

CA Integration done.
CA Policy created.
Certificate Groups created.
Cluster Policy created.

To onboard a mesh:

Go to menu > KUBE+ > Inventory > Mesh Inventory.
Click Onboard Mesh on the menu bar.

On the Onboard Mesh page, enter/select the field information for the General Information and Mesh Certificate Authority sections.

Table 2. General Information - Field and Description Table
Field	Description
General Information
Name	Enter a unique name that can be used to identify the mesh configuration associated with the specified cluster.
Cluster	Select a cluster from the dropdown list in which the service mesh needs to be configured with an external CA for signing.
Vendor	Select a service mesh vendor from the dropdown list.
Mesh Certificate Authority
Issuer CA mode	Select a radio button of Issuer CA mode. The options are: via AppViewX - This option allows to send the workload certificate signing requests directly to AppViewX and signed by the configured CA Setting (Certificate Authority). The supported CA is EJBCA. Air-Gapped - This option allows to sign the workload certificate signing requests by an Intermediate/SUB CA where the signing happens within the Kubernetes cluster. The Supported CAs are EJBCA and Microsoft CA.
Select Policy	Select the Cluster Policy from the dropdown list, which derives the associated CA for external CA signing.
Certification Authority	If you select Issuer CA mode as Air-Gapped, then enter/select the necessary details.
Ca Account	The account of the CA.
Common Name*	Common name of the certificate.
Certificate Name*	Note: This field is not applicable, if you choose Air-Gapped for Issuer CA mode. Name of the certificate.
Namespace*	Note: This field is not applicable, if you choose Air-Gapped for Issuer CA mode. Kubernetes namespace where the certificate resources are created and managed.
Secret Name*	Note: This field is not applicable, if you choose Air-Gapped for Issuer CA mode. Name of the Kubernetes Secret where the issued certificate and key are stored.
Organization	Name of the organization.
Organization unit	Name of the organization unit.
Locality	Locality of the certificate.
State	State of the certificate.
Country	Country of the certificate.
Email Address	Email address of the certificate.
Private Key Parameters
Key Type*	Select a key type of the certificate from the dropdown list. The values are: RSA ECDSA
Bit Length*	Select a bit length for RSA or ECDSA. The values for RSA are: 2048 4096 3072 The values for ECDSA are: 256 384 521

Click Generate YAML to get the commands in the Issuer CA YAML field.
Note:
- To see the commands in the full screen view, click .
- To copy the command, click .
Click Add to add the mesh to the Mesh Inventory list.

(Optional) To enable appviewx-istio-csr (gRPC Server) for Signing the External CA Certificates to ISTIOD, execute the following commands:

Download the CA certificate.
```
kubectl get secret <secret-name> -n <namespace>  -ogo-template='{{index .data "ca.crt"}}' | base64 -d > ./ca.pem
```
Note: Replace <secret-name> and <namespace> with the Kubernetes secret name and namespace that contain the CA certificate.

Create the namespace.

kubectl create namespace appviewx-istio-csr

Create the Trust Store secret.

kubectl create secret generic -n appviewx-istio-csr istio-root-ca --from-file=ca.pem=ca.pem

Install appviewx-istio-csr using helm.

helm install appviewx-istio-csr kube-plus-repo/appviewx-istio-csr \
--version <version> \
--install \
--namespace appviewx-istio-csr \
--wait \
--set "app.tls.rootCAFile=/var/run/secrets/istio-csr/ca.pem" \
--set "volumeMounts[0].name=root-ca" \
--set "volumeMounts[0].mountPath=/var/run/secrets/istio-csr" \
--set "volumes[0].name=root-ca" \
--set "volumes[0].secret.secretName=istio-root-ca" \
--set app.certorchestrator.signerName="profile.appviewx.com/istio" \
--set app.certorchestrator.issuer.name="<mesh-name>" \
--set app.certorchestrator.issuer.kind=CASettingCluster \
--set app.certorchestrator.preserveCertificateRequests=false

Note: Replace <version> with the required Helm chart version, and <mesh-name> with the name of the Istio mesh configured in your environment.

Deleting a Mesh

You can delete mesh from the inventory, if the user chooses to restrict and remove CLM operations on the designated mesh.

To delete a mesh:

Go to menu > KUBE+ > Inventory > Mesh Inventory.
Select the designated mesh, regardless of whether it is in a Managed or Unmanaged state.
Click Delete on the menu bar.
Note:
- A mesh can be removed from the inventory after deleting its associated configurations, including Cluster Policy, Issuer CA, and Certificates enrolled for the cluster, have been removed.
- Deleting mesh from the inventory will not remove the in-cluster KUBE+ components. Users are required to follow the Uninstall and Clean Up steps within the mesh to complete the removal process.

Significance of Issuer CA Mode

Issuer CA mode for External CA signing plays a vital role in optimizing the speed of certificate issuance to your application workloads running as a part of the service mesh infrastructure.

AppViewX KUBE+ supports multiple modes of Issuer CA for mTLS certificate issuance.

Issuer Mode via AppViewX : In this mode of issuing a mTLS certificate for a workload, the CSR requests are sent to AppViewX via API from the Cert-orchestrator (appviewx signer) deployed in your Kubernetes cluster to the cluster (or) environment where AppViewX is deployed.
Example : Assume an on premises k8s cluster where your workloads are running and the CSR requests are sent to the AppViewX environment provided as a SaaS service to your enterprise. In this case the network hops and delays for the CSR request to land to AppViewX and then signed by CA will not be optimal.
Also, the CSR generated by service mesh (Istio in this case) is valid for 10 seconds only for a workload and the entire process of signing the certificate by CA via AppViewX should be completed within this time frame.
AppViewX recommends to use Issuer mode as AppViewX only when the clusters running workload and AppViewX environment are nearer to each other.
Issuer Mode via Air-Gapped : In this mode of issuing a mTLS certificate for a workload, the AppViewX signer component running as a part of Cert-orchestrator generates a SUB CA / Issuing CA and the certificate and key used for signing the workloads are kept in the memory of the signer component itself for faster mTLS certificate issuance.
The signer component also keeps the signing certificate and the private key encrypted in the k8s secret for reusing it when the cert-orchestrator pods or clusters are restarted.
AppViewX recommends using Issuer mode as Air-Gapped when your AppViewX subscription is a SaaS service and when the clusters running workload and AppViewX environment are not at the nearest proximity.