VMware Tanzu Application Catalog concepts
This section provides conceptual information about VMware Tanzu Application Catalog (Tanzu Application Catalog). It is intended for anyone who wants to get started with Tanzu Application Catalog and use it to provision new Open Source applications. A basic understanding of Kubernetes and familiarity with container deployment concepts is a plus. However, in-depth knowledge of Kubernetes is not required.
The topics covered in this section are:
- Introduction
- Applications
- Base Images
- Registries
- Library
- Configurations
- Active Artifacts
- Releases
- Reports
- Interoperability
- Virtual machines
- VMware Tanzu Application Catalog for Self-Managed
Introduction
Tanzu Application Catalog is ideal for any customer that wants to stay competitive and innovative in an increasingly decentralized IT environment. Broadly, the service is applicable to all industries of all sizes, particularly those that rely on open source software in their application development processes.
Why customers should use Tanzu Application Catalog
Tanzu Application Catalog drives innovation by providing production - ready, customizable and flexible multi-cloud components to your developers. Preparing open source software from source form to production-readiness is time consuming, manual, and undifferentiated work that is often times being repeated multiple times across organizations.
Thus, key benefits of using Tanzu Application Catalog are:
- Multi-cloud: Support for all major platforms
- Customizable: Best practices, compliance, visibility
- Trusted: Stability, security, auditability
- Curated: The right content to the right teams
Understand Tanzu Application Catalog
Tanzu Application Catalog is a Software as a Service (SaaS) service that provides a curated catalog of custom-configured (to enterprise requirements) open source applications that are continuously maintained and privately delivered. Tanzu Application Catalog enables customers to drive productivity enhancements through seamlessly balancing developer flexibility and IT governance.
How does Tanzu Application Catalog work?
Tanzu Application Catalog is based on the same trusted packaging technology and automation that Bitnami, now part of VMware, has been leveraging for many years. With this service, customers will be able to choose which apps they need, which platform(s) they need them for, and what customizations are required (for example, packaging apps on top of a pre-approved “golden” operating system image).
These bespoke applications will be built, packaged, tested, continually maintained (patches, updates, and so on) and delivered to a private repository. The applications can be consumed directly into Continuous Integration pipelines from there, or can be pulled into other destinations for distribution like service catalogs.
Learn about common Tanzu Application Catalog use cases
The following are some high-level uses cases for Tanzu Application Catalog:
- Set deployment standards: Bake security, compliance and visibility into your pipelines and development processes
- Enable developer self-service: Populate and preserve deploy-ready artifacts in your repositories and service catalogs
- Automate policy: Seamlessly enforce your organization’s security posture
- Enable multi-cloud strategy: Support multiple platforms and take advantage of the latest cloud-native services
- Boost developer productivity: Provide popular components, align teams, and orchestrate best practices company-wide
- Drive Kubernetes adoption: Provide fresh and ready-to-consume content on-demand
Applications
Tanzu Application Catalog includes popular open source solutions across a variety of categories. It a customizable selection of trusted, pre-packaged open-source application components that are continuously maintained and verifiably tested for use in production environments. You may choose to add any application components to your curated catalog that is custom built-to-spec, on your operating system image of choice and delivered securely to your private registry of choice. To view the applications available in Tanzu Application Catalog, see Library.
Base images
Base images refer to a minimal operating system image that serves as a starting point for building and deploying applications within containers or virtual machines. Tanzu Application Catalog is compatible with VMware-supported operating systems and accommodates customer-provided images. For more information, see Interoperability.
Registries
Registries are the place from where the VMware Tanzu Application Catalog retrieves custom base images and publishes the applications in your catalog.
The registries supported in Tanzu Application Catalog are:
- Harbor, Azure Container Registry (ACR)
- Amazon Elastic Container Registry (AECR)
- JFrog Container Registry (JCR)
- Google Artifact Registry (GAR)
- Github Container Registry (GCR)
- Nexus Repository Manager
The Tanzu Application Catalog has multi-registry delivery capabilities, enabling administrators to concurrently add the same application to multiple registries during catalog creation. Note that Tanzu Application Catalog supports only OCI registries, but customers can request a VMware Hosted registry if needed. For more information, see Getting Started.
Library
The library provides a view of the content available in the Tanzu Application Catalog. It has essential information, including supported branches, the latest version, architecture, recent updates, licenses, and available base images for an application, along with the form factor. Library is publicly available. To explore, see Library. Clicking on “Details” allows you to access in-depth information and links to supported documentation. Note that if you are logged into the Tanzu Application Catalog, you can also view the CVE summary.
Configurations
There are two configurations available while adding new applications to your catalog:
- Basic: If you choose Basic configuration, the applications from the community edition of Bitnami Application Catalog with the associated reports will be added to your catalog.The user does not have an option to select a base image. However, automatic updates are provided for the application in the customer OCI registry. The applications added using the Basic configuration do not count towards the number of licensed artifacts in your Tanzu Application Catalog license.
- Custom: If you choose Custom configuration, user can select a base image and customize applications to meet the user’s organization policies.
For more information on how to create catalog using these configurations, see Create custom catalogs.
Active artifacts
Active artifacts are defined as a unique combination of application, format and base image, packaged for which continuous updates are enabled and delivered by the service.
Customers that purchase an entitlement to an edition of Tanzu Application Catalog can select up to the prescribed number of active artifacts.
One application in one format, one active artifact
An active artifact is any unique combination of application, format and base image. One application packaged in two different formats will result in two distinct combinations, and will thus be counted as two separate active artifacts.
Artifacts used in Basic and Custom configurations
If a customer chooses to use the Basic configuration while adding a new application to their catalog, there is no impact in the artifact count. However, if a customer chooses to use the Custom configuration while adding a new application to their catalog, every artifact chosen is counted and is reduced from the total number of artifacts available.
Extra dependencies are considered additional active artifacts
When customers add a Helm chart to their catalog, it comes with all the dependencies included: sub-charts and container images. For example, WordPress Helm chart includes the MariaDB sub-chart plus dependent container images.
If a customer wants to get a sub-chart as a standalone Helm chart - for example, MariaDB - this must be added separately when creating the catalog, and each will be counted as an additional active artifact.
Costs per active artifacts
If a customer wants to use less than the number of active artifacts offered in a purchased edition, they still have to pay the same amount for the SKU.
Each edition offers a maximum number of active artifacts. It is up to the customer to determine how many of those artifacts they choose to use.
Measure the number of used active artifacts
As customers go through the process and selecting applications and adding their configurations, the service will track and display the number of active artifacts being consumed.
Number of active artifacts to use in the Team edition
Customer can purchase multiple Team Editions if they wish to use more than 25 active artifacts.
Manage releases
Tanzu Application Catalog helps you to manage the releases of the containers and charts that you use in your applications.
Understanding the information related to chart and container releases
When selecting a container or chart catalog, you can check the information related to a specific container or chart by clicking the “Details” link.
In the resulting screen, you will find important information associated with the container or chart release:
- Status: It can be either “Pending” or “Released”. When the status is shown as “Pending”, it means that the current chart or container image version is pending to be built and released.
- Version: It indicates the current chart or container image version available in this catalog.
- Revision: It indicates the regular update that the Tanzu Application Catalog team has performed to update the components and packages included in a chart or container image version.
Understanding the differences between Digest and Container tags
When checking the details of a container image, you will see under the “Image References” section the following subsections: Digest and Container Tags.
- Digest: A unique ID that identifies the container image.
- Container Tags: “Aliases” used to specify the version/variant of a container image.
Reports
Container images and Helm charts have build time reports associated with them. These reports are generated during the build process so they contain important data (assets information, CVEs detected during the build process, and so on) for users:
Container images, Helm charts, and Virtual Machines have build time reports associated with them. These reports are generated during the build process so they contain important data (assets information, CVEs detected during the build process, and so on) for users:
| Report/Document | Purpose | Container Images | Helm Charts | Virtual Machines |
|---|---|---|---|---|
| Test Results report | Exposes the testing suite that the application passed before releasing. | Yes | Yes | Yes |
| Antivirus Scan Result report | Shows the log of the antivirus scan specifying which directories have been analyzed. | Yes | No | Yes |
| Asset Specification report | Contains information about the asset such as name, version, and the list of system packages. | Yes | Yes | No |
| CSAF VEX document | Contains a comprehensive list of reported vulnerabilities associated with the given software providing assessment details such as vulnerability status, impact, and remediation actions when available following CISA recommendations. | Yes | No | No |
| CVE Scan Result report | Contains a list of known security vulnerabilities and exposures found in the system packages at build time. | Yes | No | Yes |
| SBOM (SPDX) report | Contains metadata that identifies the software package, the package level, and the file level licensing and copyright data. This report is downloadable and also permits a graphical visualization of the data. For more information, see FAQs | Yes | Yes | Yes |
| Source Container report | Contains the source code (Dockerfile and so on) used to build the asset. | Yes | No | No |
| Trigger information report | Contains reasons for triggering the build. | Yes | Yes | Yes |
| Vulnerability CVRF report | Contains the same information as the CVE Scan report but using the CVRF industry standard to report vulnerabilities. | Yes | No | Yes |
To access these reports:
-
Navigate to a catalog, and click the “Details” link of the container image or Helm chart you want to check.
-
Scroll down to see the “Build time Reports” section.
-
Click the “Download” link to save a copy of the available reports in your local machine.
To learn how VEX leverages SBOMs and CVE scan results for an efficient vulnerability assessment, see blog post .
Antivirus scan report
The antivirus scan is performed using the ClamAV antivirus scanner. The scan is performed by mounting the container image into a known location inside the antivirus scanner image and then analyzing the location. All files in the container are scanned.
CVE scan report
The CVE scan report is performed with Trivy. The Trivy scanner checks both system packages and application dependencies, such as Bundler, Composer, npm, yarn and others.
CVE scan reports with ‘fixAvailable=true’ for some CVEs
The CVE scanner is executed every time a container image is built. At build time, the container image installs the latest available packages from the distribution’s repositories. Despite this, there are still some scenarios where the CVE report shows ‘fix available’ for a certain package or CVE:
-
The container image explicitly installs a specific older version of a package (for example, for backwards compatibility reasons). In this case, there may be a newer version of that package available with a fix for a specific CVE. If this occurs, Bitnami recommends reporting this issue to the support team, which can advise about plans to update that package.
-
The official security feed for RHEL and CentOS indicates that a fix is available, but the package that includes the fix is not available yet in the CentOS repository. This occurs because although there is a common security feed for RHEL and CentOS, the release cadence for the CentOS repository is slower than that for the RHEL repository.
As a result, new packages which have been released to the RHEL repository may not have yet been released to the CentOS repository and therefore cannot be installed in Bitnami’s CentOS-based container images. This can be directly verified by checking for the specific package that includes the fix in the CentOS repository.
NoteThe second scenario also occurs with other CVE scanners that use the official (combined) security feed for RHEL and CentOS.
CVE Scan reports with 0 CVEs for Photon OS
The CVE scanner is executed every time a container image is built. At build time, the container image installs the latest available packages from the distribution’s repositories. When the base distribution is Photon OS, there are some scenarios where the CVE report shows 0 CVEs.
The security feed for Photon OS publishes CVE information with fixes available. As Tanzu Application Catalog artifacts are rebuilt frequently, these CVE fixes are immediately applied to Tanzu Application Catalog artifacts built on Photon OS. As a result, it is very like that CVE Scan reports for Photon OS-based artifacts might show 0 CVEs.
Interoperability
Supported Base images
Kubernetes
- Debian
- Photon OS
- RedHat UBI
- Ubuntu
Supported architecture: AMD or multi-arch which includes containers for both AMD and ARM
Virtual machines
- Debian
Supported architecture: AMD
Exact supported versions can be found in the OS changelog.
Supported platforms
Kubernetes
- Platforms: TKGs on VMC, AKS, GKE, OpenShift, EKS.
- Helm version: equal or greater than 3.11.1
Supported registries
- Harbor
- Azure Container Registry (ACR)
- Amazon Elastic Container Registry (AECR)
- JFrog Container Registry (JCR)
- Google Artifact Registry (GAR)
- Github Container Registry (GCR)
- Nexus Respository Manager
Verification matrix
The matrix below displays OS distribution versions that have undergone rigorous verification against specific Kubernetes versions and cloud platforms.
These Kubernetes versions are regularly upgraded every quarter, by adding new Kubernetes versions and deprecating the older ones - following the policy stated in the Kubernetes release history. This approach guarantees that Tanzu Application Catalog Helm charts and containers are thoroughly verified and confirmed to work seamlessly in a wide array of deployment scenarios. For more information on verfication, see VMware Tanzu Application Catalog general FAQs.
| Distro version | Kubernetes Platform 1 | Kubernetes Platform 2 | Kubernetes Platform 3 |
|---|---|---|---|
| Debian 11 | TKG 1.26 | EKS 1.28 | - |
| Debian 12 | AKS 1.30 | EKS+ARM 1.28 | - |
| Photon 4 | AKS FIPS 1.30 | Air-gapped GKE env 1.29 | EKS+ARM 1.28 |
| Red Hat UBI 8 | GKE 1.29 | AKS 1.30 | - |
| Red Hat UBI 9 | OpenShift 1.25 | EKS+ARM 1.28 | - |
| Ubuntu 20.04 | TKG 1.26 | EKS 1.28 | - |
| Ubuntu 22.04 | AKS 1.30 | GKE 1.29 | - |
Virtual machine images (OVAs)
Platforms: VMware Cloud on AWS
Non-VMware platforms and Tanzu Application Catalog
There is no requirement that the output of the service (active artifacts) be consumed within VMware platforms. The artifacts are delivered to a private repository and can be consumed from there and deployed to wherever the customer chooses.
Virtual machines
Tanzu Application Catalog provides pre-packaged application templates for VMware private or hybrid-cloud environments, built to your spec and continuously validated in all supported platforms. These application templates are packaged according to industry best practices, and they provide a way for enterprise users to immediately become productive with their VMware cloud infrastructure.
