Google Cloud Marketplace BYOL

This page applies specifically to the Trinetra Kubernetes application distributed through Google Cloud Marketplace. General product documentation uses cloud-neutral language; the deployment and resource names below are intentionally Google Cloud-specific.

Commercial model

Google Cloud Marketplace deploys the Kubernetes application, but Google does not collect the Trinetra licence fee under BYOL. The customer obtains an activation key directly from LNP Technologies and separately pays Google for Google Cloud infrastructure consumption.

This software listing is not a Professional Services offer. Any assisted service is quoted and contracted separately with LNP Technologies.

Marketplace prerequisites

Prepare:

1. A supported GKE cluster and a namespace such as trinetra-system.
2. A Google Cloud project for the installation and the projects approved for discovery.
3. A Cloud Storage bucket for evidence, with versioning and customer-approved retention.
4. Dedicated Google service accounts or Workload Identity principals.
5. Viewer permissions for discovery and only the mutation permissions required for approved tests.
6. An initial administrator email address.
7. A Trinetra activation key, or the installation ID needed for LNP to issue one.

The safe Google Marketplace values template contains placeholders only. Never publish completed values or secrets.

Compatibility

• Kubernetes version declared by the 5.5.3 Marketplace schema: >=1.27.0.
• Container architecture: linux/amd64; the destination node pool must provide x86-64 nodes.
• GKE mode: use GKE Standard for the 5.5.3 Marketplace verification and supported controlled Kubernetes/node scenarios.
• GKE Autopilot: the installer can identify an Autopilot cluster, but 5.5.3 does not claim Autopilot support for disruptive Kubernetes or node-level validation. Do not use Autopilot for the Marketplace release unless LNP publishes separate validation evidence.
• Istio: marked unsupported by the 5.5.3 Marketplace schema.
• Cluster creation: disabled; select an existing GKE cluster with Workload Identity Federation enabled.

Use a currently supported GKE version that also meets the Trinetra minimum. Compatibility with >=1.27.0 does not extend Google's support lifetime for an obsolete GKE version.

Deploy from Marketplace

1. Open the Trinetra listing and select Configure or Deploy.
2. Choose the destination GKE cluster and namespace.
3. Enter the GCP project, region, evidence bucket, and optional object prefix.
4. Select the controller, UI, and probe identities.
5. Enter the initial administrator email and generate the required secrets.
6. Keep the UI service private unless a reviewed HTTPS ingress is required.
7. Optionally enter the BYOL activation key. If omitted, activate later from Licence.
8. Review the generated configuration and deploy.

Command-line Marketplace prerequisite

When using the Marketplace command-line path, install the Application CRD before the first deployment:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/application/master/config/crds/app_v1beta1_application.yaml
kubectl get crd applications.app.k8s.io

Then use the approved Marketplace chart, values, image version, and image digest with the Helm workflow.

Every Marketplace input, including generated and sensitive values, is described in Marketplace parameters.

Supported Google Cloud views in 5.5.3

• GKE Deployments and StatefulSets;
• managed instance groups;
• Compute Engine virtual-machine posture and related backup visibility;
• eligible Cloud SQL high-availability instances;
• relevant Google Cloud Audit Logs; and
• supported Backup for GKE assets when configured.

Important boundaries:

• Kubernetes mutation executes only in the controller's home cluster in 5.5.3.
• Other discovered clusters can reserve licence scope but are not remotely mutated.
• Standalone VM discovery does not imply general automatic VM recovery.
• Cloud SQL failover requires an HA instance, permissions, a licensed feature, and an explicit safety gate.
• Audit Logs are eventually consistent.

Typical IAM role families

Use dedicated identities and least privilege. Depending on enabled features, a customer review may consider Kubernetes Engine Viewer, Compute Viewer, Logs Viewer, Cloud SQL Viewer, Backup for GKE Viewer, bucket-scoped Storage Object permissions, and narrowly scoped mutation roles for approved actions. These are examples, not a complete or universal IAM prescription.

Activation lifecycle

1. Open Licence and copy the Installation ID.
2. Obtain an activation key from LNP Technologies for that customer and installation.
3. Activate and confirm the signed entitlement, expiry, features, and limits.
4. Enrol only approved projects and clusters.
5. The controller periodically revalidates the entitlement. A valid licence can use its configured offline grace period during a temporary service interruption; new activation requires connectivity.

Licence validation does not send workload contents or evidence objects to the LNP licence service.

Standard licence profiles

These are software-entitlement limits—not promises of human-led assessment or consulting. Each profile grants Trinetra activation for the stated term, licensed scope, validation-execution capacity, evidence and risk-register functionality, product onboarding, and standard product support. Human-led planning, recommendations, exercise coordination, and evidence review belong to the separately contracted Assisted service.

Custom entitlements can use negotiated terms, features, and limits. The active signed entitlement shown in Trinetra is authoritative.

What consumes a limit

• Projects and clusters are enrolled explicitly by an administrator.
• A supported resource is enrolled when its first real validation is accepted.
• An execution is consumed only after licence and safety checks reserve execution capacity.
• Dry runs and rejected preflight requests do not consume an execution.
• Repeating a test against an enrolled resource consumes another execution, not another resource slot.

Licence states and renewal

valid, near_expiry, and a configured temporary grace state allow the behavior shown in the Licence panel. no_license, expired, revoked, not_yet_valid, or invalid_signature block licensed mutations. Read-only views and existing customer evidence remain available.

Contact LNP Technologies before expiry. Include installation ID and licence ID, but never send an activation key, password, private key, kubeconfig, or evidence content.