Install Fortanix Armor

1.0 Introduction

This article describes how to deploy Fortanix Armor in a customer-managed Kubernetes environment (on-premises or cloud-hosted).

Fortanix Armor on-premises is deployed on a customer-managed Kubernetes cluster using a Fortanix-provided Helm chart and Kubernetes operator. The operator manages the lifecycle of all Fortanix Armor components, which are deployed as containerized services within the cluster.

The article assumes that the required infrastructure and prerequisites described in Prerequisites are already in place.

2.0 Key Components

For information on Fortanix Armor key components, refer to Key Components.

3.0 Fortanix Armor Architecture Diagram (On-premises)

For more information on the Fortanix Armor Architecture, refer to Fortanix Armor Architecture (On-premises).

4.0 Prerequisites

For prerequisites to install and deploy Fortanix Armor on-premises, refer to Prerequisites.

5.0 Configure Ingress Controller

Fortanix Armor requires an Ingress Controller to expose the Armor UI (user interface) and API endpoints. Ensure that an Ingress Controller is installed and configured in the Kubernetes cluster before deploying Fortanix Armor.

Example: F5 NGINX Ingress Controller can be used as an Ingress Controller.

NOTE

Fortanix does not provide or install the Ingress Controller. You can use an Ingress Controller supported by your Kubernetes environment.

For detailed steps to configure the Ingress resource, refer to Section 9.6: Ingress Configuration.

6.1 Configure Cassandra Inter-Node TLS

Starting with Armor 28.0, the Armor Kubernetes Operator Helm Chart does not create or manage the cert-manager resources required for Cassandra inter-node TLS. For a fresh installation, configure a cert-manager ClusterIssuer for Cassandra inter-node TLS. When you create the ArmorPlatform resource in Section 9.0: Create ArmorPlatform Resource and Apply the Configuration, specify the name of this ClusterIssuer in the issuerRef field.

The Public Key Infrastructure (PKI) structure and certificate authority are customer-managed. The configuration provided in this section is an example of one possible PKI structure.

NOTE

If you are upgrading an existing Armor deployment from a version earlier than Armor 28.0, refer to the Armor Upgrade Guide: Preserve Customer-Managed Resources.

6.1.1 Fresh Installations

Perform the following steps:

1. The following configuration is an example of how to configure a CA and ClusterIssuer for Cassandra inter-node TLS. You can use a different PKI structure according to your organization's requirements:

   NOTE

   The ClusterIssuer specified in the ArmorPlatform database.issuerRef field must correspond to the ClusterIssuer configured for Cassandra inter-node TLS. The example below uses cluster-issuer.

   apiVersion: cert-manager.io/v1
   kind: Issuer
   metadata:
     name: cluster-ca-issuer
     namespace: cert-manager
     labels:
       app: cluster-ca
   spec:
     selfSigned: {}
   ---
   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: cluster-ca
     namespace: cert-manager
     labels:
       app: cluster-ca
   spec:
     duration: 6480h # ~9 months
     renewBefore: 2160h # ~3 months
     secretName: cluster-ca
     commonName: cluster-ca
     isCA: true
     subject:
       organizations:
         - cert-manager
     issuerRef:
       name: cluster-ca-issuer
       kind: Issuer
   ---
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: cluster-issuer
     labels:
       app: cluster-ca
   spec:
     ca:
       secretName: cluster-ca
   

2. Run the following command to create the resources:

   kubectl apply -f cassandra-tls-resources.yaml

3. Verify that the resources were created successfully:

   kubectl get issuer cluster-ca-issuer -n cert-manager
   kubectl get certificate cluster-ca -n cert-manager
   kubectl get clusterissuer cluster-issuer

   Ensure that the cluster-ca Certificate is Ready before proceeding with the ArmorPlatform configuration.

NOTE

After the resources are created or preserved, they remain customer-managed and do not need to be recreated during subsequent Armor upgrades.

7.0 Deploy Fortanix Armor Kubernetes Operator

The following example demonstrates how to authenticate to the Fortanix OCI registry, create required namespaces and image pull secrets, and deploy the Fortanix Armor Kubernetes Operator using a Helm chart.

7.1 Operator Scope and Namespace Recommendation

• Only one instance of the Fortanix Armor Kubernetes Operator can be deployed per Kubernetes cluster.

• The operator is installed in a specific namespace (for example, armor), but operates with cluster-wide scope, allowing it to potentially manage Fortanix CCM and Fortanix Key Insight resources across multiple namespaces.

7.2 Configure and Deploy the Operator

The following example demonstrates how to authenticate to the Fortanix OCI registry, create required namespaces and image pull secrets, and deploy the Fortanix Armor Kubernetes Operator using a Helm chart

NOTE

• This example assumes that Fortanix container images and Helm charts are pulled directly from the Fortanix-managed registry.

• If your organization mirrors these images to an internal container registry, the registry URL, credentials, and Helm chart location will differ.

• The Helm chart location and configuration values are provided below. For the latest available versions of the Fortanix Armor Kubernetes Operator Helm Chart, click here.

1. The following environment variables need to be set to install Fortanix Armor Kubernetes Operator:  

   export REGISTRY_USERNAME="my_username" #replace
   export REGISTRY_PASSWORD="password" #replace 
   export OPERATOR_NAMESPACE="armor" 
   export VERSION_TO_DEPLOY="1.0.404" #replace with fortanix provided version
   export REGISTRY_URL="cr.download.fortanix.com"

   Where,

   • REGISTRY_URL: The OCI (Oracle Cloud Infrastructure) registry endpoint that hosts the Fortanix Armor container images and Helm charts (cr.download.fortanix.com).

   • REGISTRY_USERNAME: Username used to authenticate to the Fortanix OCI registry.

   • REGISTRY_PASSWORD: Password or token used to authenticate to the Fortanix OCI registry.

   • OPERATOR_NAMESPACE: The Kubernetes namespace where the Fortanix Armor Kubernetes Operator is installed (for example, armor).

   • VERSION_TO_DEPLOY: The version of the Fortanix Armor Kubernetes Operator Helm chart to be deployed.

2. Create a secret that allows the operator to pull images from the registry URL.

   kubectl create namespace "$OPERATOR_NAMESPACE" --dry-run=client -o yaml | kubectl apply -f -
   kubectl create secret docker-registry oci-registry-secret \
         --docker-server="$REGISTRY_URL" \
         --docker-username="$REGISTRY_USERNAME" \
         --docker-password="$REGISTRY_PASSWORD" \
         --docker-email="user@fortanix.net" \
         --dry-run=client -o yaml | kubectl apply -n "$OPERATOR_NAMESPACE" -f -

   Where, oci-registry-secret is the Kubernetes image pull secret created in each namespace to allow access to the Fortanix OCI registry.

3. Log in to the Fortanix registry to pull the Helm chart.

   echo "$REGISTRY_PASSWORD" | helm registry login "$REGISTRY_URL" -u "$REGISTRY_USERNAME" --password-stdin
   
   helm upgrade --install armor-platform-operator-chart \
      oci://cr.download.fortanix.com/charts/armor-platform-operator \
      --namespace "$OPERATOR_NAMESPACE" \
      --no-hooks \
      --version "$VERSION_TO_DEPLOY" #present in changelog (customer can choose which version they want to use)

   Optionally, append the following parameters to the above Helm command to schedule the operator pods on specific Kubernetes nodes:

   --set "k8ssandra-operator.nodeSelector.kubernetes\.io/hostname"="<node-name>" \
   --set "k8ssandra-operator.cass-operator.nodeSelector.kubernetes\.io/hostname"="<node-name>" \
   --set "armorPlatformOperator.nodeSelector.kubernetes\.io/hostname"="<node-name>"

   Where, <node-name> specifies the Kubernetes node name where the operator pods should be scheduled. For example, aks-sgxpool11-79929798-vmss000000.

   NOTE

   The nodeSelector configuration is optional. If not specified, Kubernetes schedules the operator pods using the cluster's default scheduling behavior.

7.3 Verify the Operator Upgrade

1. Run the following command to verify that the Fortanix Armor Kubernetes Operator is successfully deployed and is running correctly within the Kubernetes cluster.

   kubectl get pods -n <operator-namespace>

   Ensure all pods are running.

   

8.0 Configure StorageClass

Before creating the ArmorPlatform resource, ensure that a Kubernetes StorageClass is available for provisioning persistent volumes for the Cassandra database. You can use an existing StorageClass in your Kubernetes cluster or create one as shown in the following example.

kubectl apply -f - <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <storage-class-name>
provisioner: disk.csi.azure.com
parameters:
  skuName: StandardSSD_LRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
EOF

Where, <storage-class-name> is the name of the Kubernetes StorageClass used to provision persistent volumes for the Cassandra database. Use this same value in the database.storageConfig.storageClassName field of the ArmorPlatform resource.

NOTE

This example creates an Azure Disk CSI StorageClass using the disk.csi.azure.com provisioner. If you are deploying Fortanix Armor on a different Kubernetes platform, create or use a StorageClass appropriate for your environment.

Create the Armor Platform Resource configuration file. Refer to Section 9.0: Create ArmorPlatform Resource and Apply the Configuration.

9.0 Create ArmorPlatform Resource and Apply the Configuration

This section describes how to create an ArmorPlatform custom resource to define the Fortanix Armor platform configuration and trigger deployment of Armor components by the operator.

NOTE

• The following configuration is a single YAML file. It is presented in multiple sections below for readability. Use the following sample configuration as a reference and update values as required for your environment.

• Contact the Fortanix Support Team to create the correct configuration file.

• The YAML file can be found in the following path: armor-platform-operator-chart/templates/platform-crd.yaml

9.1 Base Configuration

Define the core configuration for the ArmorPlatform resource, including platform identity, replica settings, and container image configuration.

apiVersion: fortanix.com/v1
kind: ArmorPlatform
metadata:
  name: platform-test
spec:
  # Immutable once created
  name: platform-test

  # Optional Node selector used to target SGX-enabled node pools.
  nodeSelector:     
    feature.node.kubernetes.io/cpu-security.sgx.enabled: "true"

  # Confidential computing infrastructure configuration
  ccInfrastructure: # see Section 9.2

  # Optional configurations (can be omitted if defaults are sufficient)
  egress: # see Section 9.3
  enrollment: # see Section 9.4
  database: # see Section 9.5

  # Controls the number of copies of each microservice to maintain. 
  # Also controls database replicas unless explicitly defined in the 
  # Cassandra datacenter topology.
  replicas: 3

  # Default image configuration
  imageDefaults:
    pullSecretRef: "oci-registry-secret"
    registry: "cr.download.fortanix.com"

  # Optional image overrides for specific services
  imageOverrides:
    - service: alhambra
      repository: "alhambra-backend"

  # External access and certificate configuration
  ingress: # see Section 9.7

  # Internal cluster network ranges 
  # Include all pod and service CIDR ranges used by the cluster.
  internalSubnets:
    - "<pod-subnet-cidr>"
    - "<service-subnet-cidr>"
  # Used to temporarily prevent the operator from reconciling this ArmorPlatform resource.
  paused: false

NOTE

• The nodeSelector configuration is optional and supports multiple label selectors for stricter node selection.

  • For AKS deployments, the feature.node.kubernetes.io/cpu-security.sgx.enabled label must be enabled on the SGX-enabled user node pool. For instructions on configuring the labelling, refer to Prerequisites.

  • For on-premises deployments, use the intel.feature.node.kubernetes.io/sgx label for SGX-enabled nodes.

Where,

• nodeSelector (optional): Specifies node labels used to schedule Fortanix Armor workloads on SGX-enabled nodes. The required label depends on the deployment environment

• replicas: Specifies the number of instances for Fortanix Armor services and Cassandra nodes. The default value is 3.

• imageDefaults: Defines default container image registry and pull configurations for all components.

  • registry: Specifies the container registry URL hosting Fortanix Armor images.

  • pullSecretRef: Specifies the Kubernetes secret for registry authentication.

• imageOverrides: Allows specific Fortanix Armor services to use container image settings that differ from the defaults defined in imageDefaults. This is typically used when mirroring images to an internal container registry or when overriding image repositories for selected services.

  NOTE

  Contact Fortanix Support for guidance on supported service-specific image overrides.

• internalSubnets: Defines CIDR ranges representing internal cluster networks (for example, pod CIDR and service CIDR). Traffic originating from these ranges is treated as internal to the cluster. Multiple CIDRs should be specified to cover all cluster networking ranges.

• paused (optional): Temporarily suspends reconciliation of the ArmorPlatform resource. When enabled, the operator does not apply configuration changes until reconciliation is resumed.

9.2 Armor Infrastructure Configuration

Define the confidential computing infrastructure for Fortanix Armor. This section specifies the hardware-backed security technology (for example, Intel SGX) and its required configuration for enabling enclave-based workloads.

ccInfrastructure:
  sgx:
    aesmd:
      dcapProvider: azure

ccInfrastructure:
    sgx:
      aesmd: {}

Where,

• ccInfrastructure: Defines the confidential computing infrastructure configuration.

• sgx: Specifies the use of Intel SGX for confidential workloads.

• aesmd: Configures the Intel SGX Architectural Enclave Service Manager (AESM) required for SGX functionality.

  • dcapProvider: For AKS deployments, specifies the DCAP provider used for SGX attestation. Set this value to azure.

  • An empty aesmd configuration enables the default Intel SGX AESM configuration.

9.3 Egress Configuration

Fortanix Armor supports configuring an outbound proxy for connections from the Armor platform. To configure an outbound proxy, specify the proxy URL and, optionally, a list of destinations that should bypass the proxy.

egress:
  proxy:
    url: " http://<proxy-host>:<port>"
    exclude: []

Where,

• url: Specifies the URL of the outbound proxy server.

• exclude: Specifies destinations that bypass the proxy. You can specify an IP address, CIDR subnet, domain name, or * to exclude all domains from proxying.

For example: exclude a domain and IP address / CIDR subnet.

egress:
  proxy:
    url: "http://172.16.0.4:3128"
    exclude:
      - "10.10.10.0/24"
      - "example.com"

For example: exclude all domains.

egress:
  proxy:
    url: " http://172.16.0.4:3128"
    exclude:
      - "*"

9.4 Enrollment Configuration

Define the enrollment configuration for compute nodes that host the Fortanix Armor platform. This configuration controls the supported SGX types and the policies used to verify and authorize these nodes during the enrollment process.

enrollment:
  allowedSgxTypes:
    - standard
    - scalable
    - scalableWithIntegrity
  joinPolicy:
    - node-ca
    - sgx

Where,

• allowedSgxTypes: Defines the SGX enclave types that are permitted during node enrollment.

  • scalable: Specifies that the scalable SGX enclaves are permitted during node enrollment.

  • standard: Specifies that standard SGX enclaves are permitted during node enrollment.

  • scalableWithIntegrity: Specifies that scalable SGX enclaves with integrity protection are permitted during node enrollment.

• joinPolicy: Defines the validation mechanisms used during node enrollment.

  • node-ca: Validates node certificates issued by the configured node CA.

  • sgx: Validates SGX attestation evidence during enrollment.

9.5 Database Configuration

Define the storage, topology, TLS, and backup configuration for the Cassandra database used by Fortanix Armor.

database:
  datacenters:
    - name: dc1
      size: 3
      racks:
        - name: rack1
          nodeAffinityLabels: {}
            # topology.kubernetes.io/region: eastus
            # topology.kubernetes.io/zone: eastus-1

  # Optional. Defaults to the datacenter topology.
  replicationStrategy:
    dc1: 3

  #  ClusterIssuer configured for Cassandra inter-node TLS
  issuerRef: cluster-issuer

  storageConfig:
    storageClassName: "managed-csi-retain"
    storageSize: "100Gi"

  backup:
    secret: medusa-azure-key-test
    bucketName: medusa
    prefix: platform
    schedule: "30 1 * * *"

    storageProvider:
      mode: azureBlobs

Where,

• datacenters: Defines the Cassandra cluster topology, including the number of nodes and rack configuration.

• racks: Defines logical grouping of nodes within a datacenter.

  • nodeAffinityLabels (optional): Specifies node selection constraints for Cassandra pods. If not provided, pods are scheduled on any available nodes in the cluster.

• replicationStrategy (optional): Defines the replication factor per datacenter. Defaults to the datacenter topology if not explicitly specified.

• issuerRef: Specifies the name of the cert-manager ClusterIssuer used to issue TLS certificates for Cassandra inter-node TLS communication as created in Section 6.1: Configure Cassandra Inter-Node TLS. The ClusterIssuer must be configured before creating the ArmorPlatform resource.

• storageConfig:  Defines storage settings for Cassandra.

  • storageClassName: Specifies the Kubernetes StorageClass used to provision persistent volumes for the Cassandra database. Specify either an existing StorageClass or the one created in Section 8.0: Configure StorageClass.

  • storageSize: Specifies the size of the persistent volume allocated for Cassandra. Use one of the following values:

    • Production deployment: 1 TiB (1Ti)

    • Non-production environment: 500 GiB (500Gi)

• backup (optional): Defines backup configuration for Cassandra.

  • secret: Specifies the credentials for backup storage.

  • bucketName: Specifies the storage bucket or container.

  • prefix: Specifies the prefix used for organizing backups.

  • schedule: Specifies the cron schedule for backups.

  • storageProvider.mode: Specifies the backup storage provider (currently supports azureBlobs).

For detailed instructions on Cassandra backup configuration and restore procedures, refer to Backup and Restore.

9.6 Ingress Configuration

Define the external access configuration for Fortanix Armor, including domain settings for generating the API certificate and Armor UI endpoint exposure.

ingress:
  api:
    certConfig:
      subject: "armor.onprem.fortanix.com"
      sans:
        - "armor.onprem.fortanix.com"
        - "api.armor.onprem.fortanix.com"

      # Optional (for cert-manager)
      # useCertManager:
      #   kind: issuer or clusterIssuer
      #   issuer: <issuer_name>
      #   duration: 2160h

      # Optional
      # signerName: "<signer-name>"
      # expirationSeconds: 7776000
      # extraAnnotations:
      #   key: "value"

    # Optional: Proxy Protocol configuration (advanced)
    # proxyProtocolConfig:
    #   mode: disabled or maybeFrom or requiredFrom
    #   subnets:
    #     - "1.2.3.0/24"

  staticAssets:
      baseUrl: "https://static.armor.onprem.fortanix.net"
      ingress:
        ingressKind: "nginx"
        extraAnnotations:
        ingressTlsSecretName: "armor-static-secret"
      # extraAnnotations:
      #   key: "value"

Where,

• certConfig: Defines the certificate configuration for the Fortanix Armor API domain.

  • subject: Specifies the primary domain used for the Fortanix Armor API certificate.

  • sans: Specifies the Subject Alternative Names (SANs) for the certificate. For mutual TLS configurations, at least one SAN must include the  api. prefix as described in the Section 15.0: Certificate Requirement for Mutual TLS.

  • useCertManager (optional): Specifies whether automated certificate provisioning using cert-manager is enabled.

    • kind: Specifies the issuer type (issuer or clusterIssuer).

    • issuer: Specifies the name of the configured cert-manager issuer.

    • duration (optional): Specifies the certificate validity period (default value is 2160 hours).

  • signerName (optional): Specifies the certificate signer to be used.

  • extraAnnotations (optional): Specifies additional annotations applied to the generated certificate resources (for example, for NGINX configuration).

  • expirationSeconds (optional): Specifies the validity period of the issued certificate.

• proxyProtocolConfig (optional): Defines proxy protocol handling for incoming connections.

  • mode: Specifies how Proxy Protocol headers are handled.

    • disabled: Proxy Protocol is not used.

    • maybeFrom: Proxy Protocol headers are accepted from configured subnets when present.

    • requiredFrom: Proxy Protocol headers are required from configured subnets.

  • subnets: Specifies the list of CIDR ranges from which Proxy Protocol headers are accepted.

• staticAssets: Defines the configuration for serving Fortanix Armor UI static content.

  • baseUrl: Specifies the public URL to access static UI assets.

  • Ingress: Defines how static assets are exposed using Kubernetes Ingress.

    • ingressKind: Specifies the ingress implementation used to expose static assets (for example, NGINX Ingress).

    • ingressTlsSecretName (optional): Specifies the ingress implementation used to expose static assets (for example, NGINX Ingress).

    • extraAnnotations (optional): Specifies annotations passed directly to the ingress resource. These may be used for ingress-controller-specific configuration such as NGINX directives or cert-manager integration.

NOTE

• The values defined in certConfig are used by the operator to generate a CSR.

• After applying the ArmorPlatform resource, wait for the operator to generate a CSR for the configured domain. Then proceed to Section 11.0: Install Certificates to complete certificate installation.

• Changing the configured Fortanix Armor domain after deployment may affect multi-factor authentication (MFA) for existing users. For more details, refer to Section 14.2: Sign Up and Log In.

9.7 Apply the Configuration

Perform the following steps to apply the ArmorPlatform configuration to the Kubernetes cluster to initiate Fortanix Armor deployment:

1. Download the YAML file armor-platform.yaml .

2. Run the following command to apply the custom resource:

   kubectl apply -f armor-platform.yaml

10.0 Create Load Balancer

• A load balancer is typically used to provide external access to Fortanix Armor.

• The load balancer forwards client traffic to the Kubernetes Service exposing the Fortanix Armor API, which listens on port 8443.

• A single externally accessible port is sufficient for all Fortanix Armor client traffic.

Example: The following configuration demonstrates how to expose the Fortanix Armor API using a Kubernetes Service of type LoadBalancer.

NOTE

The configuration shown below is an example only. Whether a load balancer is required, and the type and configuration of the load balancer, depend on your Kubernetes platform and network environment. Configure the load balancer according to your environment.

apiVersion: v1
kind: Service
metadata:
  name: bargate-lb
  namespace: armor
spec:
  type: LoadBalancer
  ports:
    - name: https
      port: 443
      protocol: TCP
      targetPort: 8443
  selector:
    fortanix.com/api-ingress: true

Where,

• port: The port exposed to clients (for example, 443).

• targetPort: The port used by the Fortanix Armor API. In this example, it is 8443.

• selector: The label used to select the Fortanix Armor API Service pods. Use fortanix.com/api-ingress: true as shown in the example.

Run the following command to apply the example Service configuration:

kubectl apply -f bargate_loadbalancer.yml 
kubectl get service bargate-lb

11.0 Install Certificates

The following sections show how to provision TLS certificates for the Armor UI and API endpoints.

11.1 Fortanix Armor Static UI Certificates

This section describes how to generate and install a TLS certificate for the Fortanix Armor static UI.

1. Run the following commands to generate a TLS key and CSR, and create a Kubernetes TLS secret for the Armor static UI endpoint:

   openssl genrsa -out static.key 2048
   openssl req -new -key static.key -out static.csr   -subj "/CN=static.armor.onprem.fortanix.net"

2. Submit the CSR and obtain the signed certificate. Run the following command to store the certificate:

   kubectl create secret tls armor-static-secret  --cert=keys/static.crt --key=keys/static.key -n armor

   Where, armor-static-secret is the secret ingressTlsSecretName created in Section 9.6: Ingress Configuration.

12.2 Fortanix Armor API Certificate

This section describes how to provision a TLS certificate for the Fortanix Armor API endpoint using a Kubernetes Certificate Signing Request (CSR).

1. Run the following command to list the CSR objects generated by the operator for Fortanix Armor:

   kubectl -n <namespace> get csr

   Where, <namespace> is the namespace where the Fortanix Armor platform components are deployed (for example, armor).

2. Identify the CSR generated for Fortanix Armor. Run the following command to extract the CSR content generated for the Armor API certificate from Kubernetes for signing by a CA.

   The certificate chain must include:

   • The signed certificate

   • Intermediate CA certificates (if applicable)

   • Root CA certificate

   The CSR name typically follows the format: fortanix-bargate-csr-<timestamp>

   CSR_NAME=<csr-name>
   kubectl get csr "$CSR_NAME" -o jsonpath='{.spec.request}' | base64 -d > "$CSR_NAME.csr"

   Where, <csr-name> is the name of the CSR generated for the Fortanix Armor API certificate.

3. Sign the extracted CSR using your organization’s CA and prepare the certificate chain.

   NOTE

   The exact steps for signing the certificate depend on your organization’s CA and security policies.

4. Run the following command to upload the signed certificate back to the Kubernetes cluster to complete the certificate installation process:

   BASE64=$(base64 -w 0 "${CSR_NAME}-full.crt")
   
   kubectl get csr "${CSR_NAME}" -o json | \
   jq ".status.certificate = \"$BASE64\"" | \
   kubectl replace --raw "/apis/certificates.k8s.io/v1/certificatesigningrequests/${CSR_NAME}/status" -f -

   Where, CSR_NAME is the name of the CSR generated for the Fortanix Armor API certificate (for example, fortanix-bargate-csr-<timestamp>). Ensure that this value matches the CSR name used in the previous steps.

5. Run the following command to approve the uploaded certificate:

   kubectl certificate approve fortanix-bargate-csr-1776774680

13.0 Configure System Administration Settings (Using Armor API)

To configure system administration settings using the Armor API, refer to System Management.

14.0 Access Fortanix Armor UI

This section describes how to access the Fortanix Armor user interface (UI) using the configured domain after successful deployment and verify that the platform is reachable.

14.1 Verify Fortanix Armor UI Accessibility

After successful deployment and certificate installation, verify that the Fortanix Armor UI is accessible.

Perform the following steps:

1. Visit the following URL to access the static assets endpoint:

   https://<static-assets-domain>

   Where, https://<static-assets-domain> corresponds to the staticAssetsBaseUrl configured in Section 9.6: Ingress Configuration.

   For example: https://static.onprem.fortanix.com

2. If prompted, accept the browser warning about the TLS certificate (when using self-signed certificates).

3. Access the Fortanix Armor UI at https://<armor-domain>. This domain corresponds to the certConfig.subject configured in Section 9.6: Ingress Configuration.

4. Confirm that the login page is displayed successfully.

14.2 Sign Up and Log In

Perform the following steps to sign up for Fortanix Armor:

1. Visit https://<armor-domain> and sign up.

   NOTE

   • The first user to sign up for Fortanix Armor and create an account automatically assumes the role of system administrator.

   • Multi-factor authentication (MFA) device registrations are bound to the domain name through which the registration was performed. If the Fortanix Armor domain name is changed after users have registered MFA devices, those devices will no longer be valid for authentication using the new domain. Users may need to re-register their MFA devices after a domain change. Plan the production domain name carefully before onboarding users and enabling MFA.

2. Once you sign up, enter your email address and password, and click LOG IN.

   

For detailed steps to log in to Fortanix Armor, refer to Access and Set Up Fortanix Armor.

14.3 Create and Select an Account

For detailed instructions to create an account, refer to Access and Set Up Fortanix Armor.

14.4 References

To know the features available for Fortanix CCM on-premises deployments, refer to the Fortanix CCM Feature Support Matrix (SaaS vs On-premises).

To know the features available for Fortanix Key Insight, refer to the Fortanix Key Insight Overview.

15.0 Certificate Requirement for Mutual TLS

For connections that require mutual TLS (for example, Node Agent communication), the public certificate must include a SAN that begins with the following:

api.<your-domain>

NOTE

Ensure that the domain defined for mutual TLS aligns with the certificate configuration provided in Section 9.6: Ingress Configuration.