T4K Product Quickview | Trilio for Kubernetes

Trilio uses only fully supported Kubernetes APIs and features. T4K has been developed to best practices, avoiding the use of Kubernetes alpha APIs and using hard-coded Kubernetes API versions.

Best practices for Trilio for Kubernetes software development include:

Deployable by a single Helm or Operator artifact.
Product editions are licensed as an item and are tied together by a Helm or Operator artifacts.
Supports consecutive Red Hat OpenShift Container Platform minor versions.
Software images are consistently maintained across offerings.
Binaries based on Red Hat UBI.
All Images are Red Hat Certified.
T4K has been integrated with Red Hat publishing per content guidelines.
T4K supports Operator based install.
T4K Operators are OLM (Operator Lifecycle Manager) enabled.
All T4K Custom Resource Definitions (CRDs) include application version.
All Operators provide a status. __

In order to be defined as Production Grade, all Red Hat apps must pass QA requirements for documentation, system requirements, best practices for resource usage, data integrity testing and cluster behaviors (scaling, recovery, dependancies)

Minimum cluster configuration and physical resources are published
1. Cluster configurations are validated and updated on major product releases.
All persistent volumes storage access modes. RWO – ReadWriteOnce.
Trilio maintains Data integrity during pod or node failures.
Trilio for Kubernetes uses fully qualified hostnames to provide external access.
Trilio does NOT use custom ingress annotations for external access.
Trilio does NOT use Nodeports to provide external access.
Trilio supports advanced scheduling to ensure maximum resiliency.
To provide resiliency when unexpected failures occur , T4K supports graceful recovery when failure occurs
Monitoring provides application health and react to events.
Trilio data protection has the ability to run in multiple failure zones in a single cluster.
Deployments can scale horizontally with manual scaling
Scalability can be achieved by deploying multiple instances in a single cluster without conflict.

All images have been scanned using Red Hat Certification VA Scanner and Linter (IBM Approved scanning tools).
T4K follows a principle of least privilege and pod isolation
T4K uses an approved SCC definition
T4K provides exact capabilities required for SCC
All components of a workload are tracked, including Helm release, Namespace, Labels and Annotations, so if something is created maliciously this can be readily detected.
Workloads do not use the default service account. For all workloads, we use `k8s-triliovault service account only which gets provisioned during TVK installation.
T4K Only exposes required ports/services from each container
T4K limits traffic between pods.
Containers do not communicate with the host.
All data is encrypted in transit using TLS 1.2 within the customer network between Pods.
Encryption for data at rest can be managed by the backup repository used by customer (NFS/S3). T4K doesn't encrypt at rest, this is left to the NFS or S3 repository
All Secrets are stored in an approved service
Logs are clear of all sensitive information and does not expose any sensitive data.
Helm release is clear of sensitive information and do not expose any sensitive data.
Kubernetes Resources (other than a secret) do not store sensitive information
Default credentials to be immediately updated by the customer are not supplied by Trilio.
All communication between containers and services uses TLS auth in order to restrict anonymous access.
T4K Uses an IBM approved certificate manager -Certificate type is X.509 and follows best practices for Public Key Infrastructure.

methods include:

In Place Upgrade

T4K Upgrade paths follow best practices for:

Provide non-disruptive patching for image updates.
Upgrade ensures no loss of vital data.
Upgrade path is documented in Release Notes.
Upgrade path tested.

T4K has defined methods for workload rollbacks using Kubernetes Native Rollback. T4K documentation of backup/recovery process includes

Backup points documented externally for clients
Recovery / restore is documented externally for clients
Backup and recovery of application and data is well tested for each major release

Trilio completes comprehensive testing. Broad tests are designed and performed for the product. A wide range of testing methodologies are used to ensure the quality of the product, including:

Unit testing
Integration testing
System testing
Availability testing
Install testing
Performance testing
Beta customer testing

Other QA items:

includes steps for customer to validate successful install. Customer-driven post-install tests allow for the customer to validate that your product was installed successfully and is running correctly.
T4K can also be in an air gap environment. T4K has a install process and verification for a disconnected network (air gap environment).
T4K has been tested on all Red Hat OCP versions that the product has declared support.
T4K has storage options that are supported and tested.

T4K provides a for obtaining support
T4K licenses are available in the package source. All product licenses deployed by a workload are available with the source (Helm, Operators, or CASE).
All (Helm chart, Operator controller/CRD, CASE, scripts, dashboards) are Apache 2 licensed.
T4K licenses align appropriately for Docker images and package source. License files in the Docker images align with the license files put in the packaged source for your product.
T4K displays all relevant licenses for acceptance based on the deployment scenario for the workload.

Trilio uses the latest UBI minimal images as the starting point for all product images. UBI minimal images are substantially smaller than the regular UBI images and are a better starting point for product images.

Trilio reduces the number of unused files and image layers in all images.
Trilio uses only one runtime framework (Node.js, Python, Golang) in a container.
T4K uses only curl or wget to fetch packages from remote URLs.