This section provides answers to general VMware Tanzu Application Catalog (Tanzu Application Catalog) questions.
Customers can work with the Tanzu Application Catalog sales team to receive an invitation to use the service. These are the typical steps for onboarding and quickly use Tanzu Application Catalog:
To learn more, see Get Started with VMware Tanzu Application Catalog guide.
For further questions and inquires, contact Tanzu Application Catalog.
Tanzu Application Catalog is delivered via VMware’s Cloud Services Portal (CSP). Once an entitlement to the service is purchased, customers can log-in to CSP with their existing credentials and add the Tanzu Application Catalog tile to their list of CSP services. For more information on CSP, see User Guide.
The Tanzu Application Catalog provides users with a free 90-day trial period. When this period is about to end, users will see the following message when accessing their Tanzu Application Catalog accounts: “Your trial is going to expire”. In that case, contact your VMware sales representative to learn more about how to subscribe to any of the available editions that you can purchase for your team.
There are two types of roles that can be assigned to use Tanzu Application Catalog:
Open CVEs are the ones that have not been fixed by the Linux Distribution maintainers because they did not work on that yet or they do not consider a critical issue. The Tanzu Application Catalog team is not able to fix those CVEs since those fixes depend directly on the distribution maintainers.
Tanzu Application Catalog’s images are based on various operating systems, including Debian, Photon, RedHat UBI, and Ubuntu. These CVEs exist in these distributions as well as other distributions which depend on them or use them.
CVE information is available in the CVE Scan report for each Tanzu Application Catalog container image and virtual machine. To access this, navigate to a catalog, and click the “Details” link of the container image you wish to check. To check CVE information for a Helm chart, check the CVE Scan report for each of its dependent container images.
The Tanzu Application Catalog team has launched a public CVE security feed available on GitHub to better enable vulnerability scanners to detect vulnerabilities in the custom-build components included in the Bitnami packages.
Customers that use Trivy as the security scanner to detect vulnerabilities in their containers can check vulnerabilities in Bitnami components. Trivy integrates the Bitnami security feed since version v0.45.0.
The Bitnami CVE security feed is publicly available and it can be consumed by any security scanner that supports the Open Source Vulnerability Database (OSV) schema.
If your security scanner does not support the Bitnami CVE feed, please contact your provider to request its integration. This will enable you to receive Bitnami component analysis in your vulnerability scanner results.
To learn more, see blog post announcement.
Tanzu Application Catalog containers and Helm charts do not include fixable CVEs.
To ensure that all Tanzu Application Catalog images include the latest security fixes, Tanzu Application Catalog implements the following policies:
Tanzu Application Catalog triggers a release of a new Helm chart when a new version of the main server or application is detected.
For example, if the system automatically detects a new version of MariaDB, the Tanzu Application Catalog pipeline automatically releases a new container with that version and also releases the corresponding Helm chart if it passes all tests. That way, Tanzu Application Catalog ensures that the application version released is always the latest stable one and has the latest security fixes.
Tanzu Application Catalog triggers a release of a new chart when a package that includes a fix for a CVE from the distribution in any of the containers that it includes is detected.
The system scans all our containers and releases new images daily with the latest available system packages. Once the pipeline detects there is a new package that fixes a CVE, our team triggers the release of a new Helm chart to point to the latest container images.
The Tanzu Application Catalog team monitors different CVE feeds - such as Heartbleed or Shellshock - to fix the most critical issues as soon as possible.
Once a critical issue is detected in any of the charts included in the Tanzu Application Catalog catalog, a new solution is released. Tanzu Application Catalog provide updates in less than 48 business hours.
Currently Tanzu Application Catalog supports SPDX format for SBoM but not CycloneDX. However, you can convert the existing SPDX format files to CycloneDX format files using Syft CLI. Once converted, the CycloneDX format files can be imported in Dependency-Track or any other tool to visualize information of that SBoM specific type.
To convert SPDX file to CycloneDX file using Syft CLI:
Download the SPDX file from Tanzu Application Catalog UI:
In the “My Applications” tab, from the list of all applications click the “DETAILS” button corresponding to the container image, Helm chart, or virtual machine, whose SBoM you need.
In the Build Time Reports section, find and download the SBoM (SPDX) report to your PC. The report is a JSON-formatted file containing multiple sections. It can be read using any text editor or JSON-compatible client library, making it immediately usable in other applications.
Open the Syft CLI and change to the directory where the SPDX file was downloaded.
Run the command, for example,
syft convert apache.spdx -o cyclonedx-json=apache-cyclonedx.json
The SPDX file is converted to a CycloneDX and will be available in the same folder where the SPDX file was downloaded.
To view SBoM information in Dependency-Track:
Click “Upload SBOM” to import the CycloneDX file and view all the software components.
(Optional) Click the “Dependency graph” tab to view which dependencies are related to which software component.
Converting files from one format to other has a known limitation where specific license IDs could not be identified or linked in Dependency-Track UI.
There are two configurations available while adding new applications to your catalog:
This allows you to have a single private catalog containing both community edition of Bitnami Application Catalog and customized catalogs in your private repository with your Tanzu Application Catalog subscription. This also helps in having an even upgrade experience when moving from Bitnami Application Catalog to Tanzu Application Catalog.
For more information, see Configurations.
Tanzu Application Catalog applications are verified across various combinations of Kubernetes versions, cloud platforms, and base OS distribution versions.
As a result, customers can be confident that the applications included in their catalogs are continuously tested and proven to be suitable for production environments reducing the risk of failure at deployment time.
One form factor, four verifications
Each Tanzu Application Catalog Helm chart distribution is verified in four different Kubernetes versions.
The entire Tanzu Application Catalog is also tested against major cloud platforms covering more than 90% of deployment scenarios. For more information, see Interoperability.
All container images, Helm charts, and virtual machines available in the catalog are continuously verified to ensure they include the latest dependencies and minimal CVEs.
New versions are only released after they meet specific conditions. This ensures that only relevant updates are delivered to customer registries.
A new container is triggered so long it fulfils any of the following cases:
A new Helm chart is triggered so long as it fulfills any of the following cases:
A new VM is triggered so long it fulfils any of the following cases:
| NOTE: For additional information about the reasons fir triggering the build, you can download a “Trigger information” report from the applications details page. See Reports.
Yes, in addition to the default AMD64 format, certain distributions and applications that also support ARM64 architecture were verified and found to run in major cloud platforms.
Customers can check if the Helm charts available in Tanzu Application Catalog library are security compliant based on:
Go to Tanzu Application Catalog and sign in using your VMware Account. After signing into Tanzu Application Catalog, from the left navigation page, click “Library”.
You can check the security requirements in one of the following ways:
Scroll down to the application you want to check. Tags displayed under the application name indicate the applicable security requirements.
Filter by “Security” from the list of filters displayed on the left-side of the page.
Select an application and click on the “Details” link. In the table that displays, the “Validation Platforms” column indicates the security requirements this chart has been verified against.
Once an application has been added to your catalog, go to “Application” from the left navigation pane. Click on the “Details” link and download the test-results.tar.gz file. If that Helm chart has been verified to meet any security requirements, the file name will indicate that condition.
Yes, the verification process involves testing at least two distribution versions on two different Kubernetes platforms to ensure compatibility in air-gapped environments.
To check if an application has been verified for use in air-gapped environments, see How can I check if a Helm chart is configured correctly to meet specific security requirements?.
Yes, currently Photon OS distributions are verified to be compliant with AKS FIPS.
To check if an application has been verified for FIPS, see How can I check if a Helm chart is configured correctly to meet specific security requirements?.
Yes, as part of the verification process, certain distributions were verified and found to run on OpenShift, with a specific requirement for a non-root and random-UID configuration.
To check if a Helm chart works with non-root containers see How can I check if a Helm chart is configured correctly to meet specific security requirements?.
Bitnami application packages available through Tanzu Application Catalog — containers, Helm charts, and OVAs — are built with best practices, kept up to date with the latest application versions, and go through extensive automated tests and verifications to run in their target platforms with the expected behavior and performance. Each application package comes ready to use, requiring no additional setup.
Tanzu Application Catalog applications run through the following tests and validations:
Functional: Verifies that the application works as expected depending on functional requirements and specifications. These verifications are:
End-to-end testing: Validates that the potential deployed software runs from end to end as expected. Tanzu Application Catalog team uses Cypress as an E2E testing framework. In web applications, for example, these verifications include checks on login and logout actions, creation of posts, projects, tickets, plugin installation, and so on. Additionally, other actions are executed such as creating a database, make sure the database is replicated in a high-availability configuration, API queries, create events/topics and make sure they are received, actions in the CLI, and so on.
Persistence: Checks that the pod or image can be removed and the data is properly configured in an external volume.
To learn more about Bitnami functional tests, see blog post .
Additionally, to enforce the security of container images they are configured with a non-root user.
Apart from these validations, Tanzu Application Catalog applications run through rigorous verifications against specific Kubernetes versions and platforms as well have been verified to use in air-gapped and OpenShift environments, and to be verified in FIPS environments. For more information, see How to check if a Helm chart is configured to meet specific security requirements, How is Tanzu Application Catalog continuously tested to be used in production environments, and verification matrix to check the specific Kubernetes and cloud platforms the catalog is verified against.