TrilioVault uses only fully supported Kubernetes APIs and features. TVK has been developed to best practices, avoiding the use of Kubernetes alpha APIs and using hard-coded Kubernetes API versions.
Best practices for TrilioVault 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.
TVK has been integrated with Red Hat publishing per content guidelines.
TVK supports Operator based install.
TVK Operators are OLM (Operator Lifecycle Manager) enabled.
All TVK 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)
All persistent volumes storage access modes. RWO – ReadWriteOnce.
Trilio maintains Data integrity during pod or node failures.
TrilioVault 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.
TrilioVault supports advanced scheduling to ensure maximum resiliency.
To provide resiliency when unexpected failures occur , TVK 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).
TVK follows a principle of least privilege and pod isolation
TVK uses an approved SCC definition
TVK 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
TVK Only exposes required ports/services from each container
TVK 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). TVK 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.
TVK Uses an IBM approved certificate manager -Certificate type is X.509 and follows best practices for Public Key Infrastructure.
Upgrade methods include:
In Place Upgrade
TVK 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.
TVK has defined methods for workload rollbacks using Kubernetes Native Rollback. TVK 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:
Beta customer testing
Other QA items:
TVK documentation 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.
TVK can also be installed in an air gap environment. TVK has a install process and verification for a disconnected network (air gap environment).
TVK has been tested on all Red Hat OCP versions that the product has declared support.
TVK has documented storage options that are supported and tested.
TVK provides a process for obtaining support
TVK licenses are available in the package source. All product licenses deployed by a workload are available with the source (Helm, Operators, or CASE).
All package source (Helm chart, Operator controller/CRD, CASE, scripts, dashboards) are Apache 2 licensed.
TVK 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.
TVK 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.
TVK uses only curl or wget to fetch packages from remote URLs.