Thursday, April 28, 2022

Use Enterprise-Grade Bitnami Apps in Production with VMware Application Catalog

Originally published on the VMware Tanzu blog

Shagun Tewari and Raquel Campuzano Godoy co-wrote this post.

For the past fifteen years, the Bitnami team has delivered pre-packaged open source applications to millions of developers. Over that time, we have evolved our application catalog from delivering our stacks in the form of installers and virtual machines, to cloud native applications, containers, and Helm charts that help you build applications on any platform. Developers use the Bitnami solutions through the Bitnami Application Catalog, which is our name for the catalog available through marketplaces and on Bitnami.com. 

With over three million developers using our solutions today, there’s no doubt that Bitnami Application Catalog solutions are extremely popular and are ideal for testing purposes in development environments. 

There are, however, constraints with trying to deploy any open-source software in production/enterprise environments, including those from Bitnami Application Catalog. According to a VMware Tanzu survey taken in 2021 on the state of the software supply chain, 95 percent of respondents mentioned that there is no guarantee that vulnerabilities will be remediated, given that ownership of open-source software, in general, remains unclear. Moreover, respondents stated that it’s difficult to keep up-to-date on vulnerabilities so that they can be addressed in time. In reality, keeping up-to-date on every software and dependency vulnerability, and patching in upstream source code, is an enormous effort that few organizations can afford. It is not viable for developer teams to manually track every dependency and to make sure that application components are always updated, healthy, and patched with the latest vulnerability fixes—while guaranteeing internal compliance—instead of focusing on building new business solutions. 

This is where VMware Application Catalog comes in. With VMware Application Catalog, development teams can utilize a rich library of custom, pre-packaged, and trusted building blocks for private enterprise consumption delivered as containers, Helm charts, and virtual machines. These application building blocks are tested on multiple deployment platforms and are continuously and automatically updated for every new vulnerability fix, including those for all dependencies, thanks to an internal automatic build pipeline. 


What is VMware Application Catalog? 

Developers love open source software because it helps energize their application development cycles and offers a wide variety of community-backed technology to choose from. How do we bring these benefits into enterprise environments while avoiding any potential security pitfalls? 

VMware Application Catalog is a customizable selection of trusted, pre-packaged open-source application components that are continuously maintained and verifiably tested for use in production environments.  

It is a library of production-ready Open Virtual Appliances (OVAs), containers, and Helm charts ranging from solutions to integrated code, development applications, automation tools, databases, and other backing services. These catalog images can be plugged into any stage of your company's software lifecycle.

VMware Application Catalog brings users a rich library of pre-packaged open source components in the form of Helm charts, containers, and OVAs. 


So what exactly is special about these images? This catalog can be custom-packaged on any base operating system (OS) provided by a customer. Customers may provide custom golden base OS images or choose from a set of OS images provided by VMware. 

Then, multiple functional and verification tests are run on the packaged image, including build-time Common Vulnerabilities and Exposures (CVE), antivirus scanning, and deployment testing on various platforms. 

Finally, the hardened image, along with the image metadata that contains all vulnerability, antivirus scan, and deployment test results, is pushed to a registry of the customer’s choice for secure, private consumption. 

And last but not the least, VMware Application Catalog offers continuous monitoring of upstream source code changes to automatically trigger image rebuild, testing, and pushes to register new and fixed images. This means that the catalog is always up-to-date. 


How is VMware Application Catalog different from Bitnami Application Catalog?  

A legitimate question for current Bitnami Application Catalog users is: how does VMware Application Catalog differ from Bitnami’s free content? We can sum up the differences by saying that Bitnami Application Catalog is a standard catalog built for the community, while VMware Application Catalog is a custom catalog designed for the enterprise. This statement condenses a list of significant differences such as: 

  • Individual vs enterprise: Bitnami Application Catalog provides software that is intended for a wide range of developers, while VMware Application Catalog supplies a library of assets specifically built to address the security needs of a specific enterprise. 
  • Customization flexibility: Bitnami Application Catalog stacks are built on only one standardized base OS image: Debian. VMware Application Catalog customers can choose to have their images packaged on top of their own golden image (e.g., their own Center for Internet Security-certified Photon OS image), or choose from several hardened Linux flavors provided by VMware Application Catalog.


VMware Application Catalog provides many different base OS images to choose from.

 

  • Automatic image library refresh: Bitnami Application Catalog releases a new version of its images every time there is a security fix, patch, or new major version available in the upstream code. However, if they’d like to use the refreshed images, developers are required to navigate to the catalog and redeploy the image to update it. With VMware Application Catalog, images are automatically rebuilt and pushed to the private registry every time there is a new version available in the upstream community to ensure the catalog is always fresh. 
  • Detailed bill of materials and metadata for proof of provenance: To get information about the stacks they are running, Bitnami users go to DockerHub or GitHub repositories. VMware Application Catalog users have direct access to extensive metadata in their repositories, which eliminates the need to monitor any external sources. Extensive metadata is served in a JSON file that has information on how to consume the asset, its digest, its build, and release dates, and a complete list of included subcomponents or libraries with license information. We also provide detailed results for CVE, antivirus, and deployment to platform tests, as well as other functional and verification tests conducted on the image for full transparency and visibility. Further, this metadata is digitally signed using a cosignatory to protect it from tampering, which adds another layer of security to the catalog. 


Each asset available in the catalog provides users with all the information they need to consume it.

An example of a test results report which shows all the tests the application went through before being added to the customer’s catalog.


How Bitnami Application Catalog users can benefit from VMware Application Catalog 

Bitnami Application Catalog images are ideal for personal use or development environments, where the stakes are not so high. When it comes to enterprise-grade applications, software supply chain security is of the utmost importance, and developers must abide by strict IT compliance and security rules. VMware Application Catalog provides the goodness of open-source software that developers need to move faster while adhering to security and compliance regulations demanded by the operations and security teams. 

If an enterprise manages a dozen sites, this level of transparency and compliance may be achievable with the work of a single developer or by a small team. However, for large enterprises, moving to production usually means managing hundreds of thousands of applications and sites. In this scenario, companies are forced to dedicate part of their development and site-reliability engineering resources to more tedious tasks, such as tracking all application dependencies and making sure that they are kept up-to-date and patched with the latest CVE fixes to ensure internal compliance. 

VMware Application Catalog allows customers to request images that are custom-packaged on an OS of choice, hardened, security tested, and delivered to a private repository. This frees up developers from the necessity of building their own compliant application components, as well as monitoring external sources and the upstream code to keep their open-source images current. It also provides the security and operations team with detailed metadata for increased visibility and assurance that their software is secure and up-to-date. VMware Application Catalog promotes developer productivity while boosting operator and security team confidence.


Learn more about VMware Application Catalog 

To learn more about VMware Application Catalog, join our webinar session on June 23 at 10 AM PT. Register now for the session! 

For additional information, read about VMware Application Catalog on our product page, browse through all applications available on VMware Application Catalog, or read our newly updated technical documentation. 

For more questions, reach out to the product team directly at app-catalog@vmware.com.


Thursday, March 31, 2022

Kubeapps 2.4.3 - Now Supports for Carvel and Flux Packages

Michael Nelson and Raquel Campuzano co-wrote this blog post 

A new release of Kubeapps is out, and it introduces major changes that mark a milestone in the history of this tool. We are thrilled to announce that the support of different Kubernetes packages has now become a reality with the implementation of the Kubeapps API service. Helm charts are no longer the only option to choose from: now Kubeapps users can deploy Carvel and Flux packages as well! 

In addition to this new capability, the Kubeapps team has solved a long-standing security issue by removing the reverse proxy to Kubernetes API server.  

Keep reading to learn more about how the team has implemented a pluggable architecture that allows users to discover new implementation that make Kubeapps a robust and secure way to deploy applications on Kubernetes infrastructure.  

We will also cover how to deploy and manage Carvel and Flux packages from the Kubeapps user interface (UI).  

Kubeapps APIs – A Pluggable System Supporting Different Kubernetes Packages 

The design of the Kubeapps APIs server solves two main goals for Kubeapps. 

1. Enable pluggable support for presenting catalogs of different Kubernetes packaging formats for installation 

Kubeapps coupled to HelmPrior to this release, Kubeapps was tied closely to the Helm packaging API for listing, installing, and updating Helm charts. The team has abstracted the functionality for listing, installing, and updating packages so that it can be applied to other packaging formats apart from Helm charts. 

Each format is supported by a plugin that implements a core gRPC protocol for package interactions. Since each plugin implements the same packages protocol, Kubeapps can present the results from multiple plugins in the UI, so that, for example, both Helm and Carvel packages can be seen in the catalog together.  

2. Remove the long-standing requirement for the Kubeapps UI to talk directly with the Kubernetes API server 

Kubeapps UI gathering data via the resources pluginSimilarly, prior to this release, the Kubeapps UI needed to communicate directly with the Kubernetes API server and as a result, Kubeapps forwarded requests from the Kubeapps UI through to the Kubernetes API server. The team has now encapsulated the functionality required by the Kubeapps UI into a separate Kubernetes Resources plugin, which allows the Kubeapps UI to, for example, fetch or watch resources created by a specific installed package (if the authenticated user has access to those resources). 

With this change, only a very limited subset of the functionality of the Kubernetes API server is available to the Kubeapps UI. 

A side-effect of these changes is that the client code in the Kubeapps UI can be simplified significantly, which is not only easier to maintain but also opens the possibility for other Kubeapps clients. 

For more details about the implementation of the Kubeapps APIs service, see Kubeapps APIs: A pluggable system supporting different Kubernetes packages. 

New Package Types Discoverable through the Kubeapps UI  

This new release comes with new features and capabilities that provide cluster administrators and operators more flexibility when deploying applications on their Kubernetes environments. Let’s deep dive into them! 

Update your Helm repositories to ensure that you have the latest Kubeapps version. Refer to the Get Started guide to learn how to deploy Kubeapps for your cluster.  

Once you have made some configurations in your cluster and set up Kubeapps to enable Carvel and Flux packages, you will be able to find packages labelled as Helm, Carvel, and Flux when navigating to the “Catalog” section.  


 

The process of deploying Carvel and/or Flux packages from the Kubeapps UI and managing applications is similar to the processes followed for a Helm chart, but there are some requirements that your cluster must carry out to make sure that the deployment of these new packaging formats will work. 

Deploy and Manage Carvel Packages with Kubeapps 

Check out this step-by-step guide to learn how to manage Carvel packages with Kubeapps. 

Carvel is usually defined as a set of tools that helps you to build and configure applications for their deployment on Kubernetes. To enable the consumption of Carvel packages from the Kubeapps UI, you must make some configurations first. 

These are the pre-requisite steps to follow to make sure that both your cluster and Kubeapps deployment are ready to work with Carvel packages: 

  1. Install kapp-controller in your cluster 
  2. Configure Kubeapps to support Carvel packages 
  3. Install a package repository 
  4. Create a service account in your namespace 

Once everything is arranged, you’ll be ready to pick packages to deploy on the Kubeapps UI by navigating to the “Catalog” section. 

  • Log in to Kubeapps and navigate to the “Catalog” section. Search for Carvel packages:  


  • Pick an application to deploy. This blog post uses Contour as an example, but you can choose any other application from your catalog. 

You will find detailed information about the package you’re about to deploy such as the requirements, release notes, where to find support, licenses, or the maintainers of the image. 

  • Select the version you want to deploy. And click “Deploy” to continue:  


  • In the resulting screen, add a name for your deployment, select the service account, and make changes to the YAML file if applicable. Click “Deploy” to finish the process.  


  • Navigate to the “Applications” section. If the deployment went smoothly, your application will show a green label saying that the package was installed successfully in your cluster.  
  • Click on “Show apps in all namespaces” to get an overview of the applications running in your cluster regardless of the namespace.  

  • Look at the deployment details by clicking on the application you just deployed.  

In the resulting screen, you will have access to meaningful information such as the number of pods deployed, access URLs, secrets, installation notes, and application resources. Note that from this page, you can also upgrade your application to the next version available or delete it from your cluster.  


 Deploy and Manage Flux Packages with Kubeapps 

Check out this step-by-step guide to learn how to manage Flux V2 packages with Kubeapps. 

Flux is a set of continuous and progressive delivery solutions for Kubernetes that are open and extensible. The latest version of Kubeapps allows you to manage Helm releases declaratively with Kubernetes manifests via Fluxv2. Similar to Carvel packages, there are some previous configurations that you must perform in your cluster and Kubeapps installation to fully activate Flux packaging support.  

These are the pre-requisite steps to follow to make sure that both your cluster and Kubeapps deployment are ready to work with Carvel packages: 

  1. Install Flux controllers in your cluster 
  2. Configure Kubeapps to support Flux Helm release 
  3. Install a Flux Helm repository 
  4. Create a service account in your namespace 

Now everything is ready for the deployment of Helm packages via Flux.  

  • Log in to Kubeapps and navigate to the “Catalog” section. Search for Flux packages:  


  • Pick the package you want to install. We use Apache as an example.  


Enter the configuration parameters for your deployment. Note that for Flux, you must enter a ServiceAccount to be used for installing the package. Apart from that, the process for deploying and managing Flux packages is similar to those for any other packages available in Kubeapps.   

Laying Down the Foundation for Future Improvements 

Thanks to the implementation of the Kubeapps API service, we will be able to move forward and support different packaging formats in the future as the Kubernetes landscape and the needs of users will evolve. The current release lays down the foundation for making Kubeapps a more inclusive and secure path for Kubernetes deployments.  

Support and resources   

Since Kubeapps is an OSS project, support for this version of Kubeapps will be provided on a best-effort basis. To get a resolution on issues such as deployment support, operational support, and bug fixes, please open an issue in the Kubeapps GitHub repository. A markdown template is provided by default to open new issues, with certain information requested to help us prioritize and respond as soon as possible. Also, if you want to contribute to the project, feel free to send us a pull request, and the team will check it and guide you in the process for a successful merge.  

In addition, you can reach out to Kubeapps developers at #kubeapps on Kubernetes Slack (click here to sign up).  

For more information about the topics discussed in this blog post, refer to the following links:  

Tuesday, November 30, 2021

Fix Issues in Your Code Before Going to Production in Minutes with SonarQube

Carlos Rodríguez and Raquel Campuzano co-wrote this blog post

SonarQube is an open-source code analyser designed for analysing and measuring the technical quality of code. This is particularly useful to avoid the need of fixing issues when your applications are already running in production environments. With SonarQube you can keep your code clean and prevent future vulnerabilities from the earliest stages of development to production.  

It combines static and dynamic analysis tools to monitor the following: 

  • Duplicated code 
  • Compliance with coding standards 
  • Unit tests 
  • Complex code 
  • Potential bugs 
  • Comments and design 
  • Code architecture 

SonarQube is used for major programming languages such as C/C++, JavaScript, Java, C#, PHP, or Python, amongst others. Often, applications use several programming languages simultaneously, for example, a combination of Java, JavaScript, and HTML. SonarQube automatically detects these languages and invokes the corresponding analyzers. 

Sonarqube was available in the Bitnami Application Catalog for its local deployment or in the cloud, and now, you can also deploy it on your Kubernetes cluster as a Helm chart.  

Keep reading to learn how to install it in your cluster to start analysing your code in minutes.  

How to Install the SonarQube Helm chart in your Kubernetes Cluster 

Having SonarQube running in your cluster is as easy as executing a couple of commands.  

First, install the Bitnami Helm charts repository by executing the following: 

helm repo add bitnami https://charts.bitnami.com/bitnami 

Once the repo is installed in your chart, run the command below to finish the installation of the SonarQube Helm chart:   

helm install my-release bitnami/sonarqube 

Remember that “my-release” is a placeholder, you can replace it with an identifiable name for your release.  

Once the deployment completes, refer to the output to obtain the SonarQube URL and credentials.  

To start using SonarQube, execute the corresponding command to get the URL. Then, open a browser and enter the IP address you have obtained. You will see the login screen: 

Enter the username “user” and the password obtained by running the command shown in the deployment notes. 

That’s all! Now you can start analysing your code! In the following sections, you will find a sample JavaScript code and some examples of how to use SonarQube to detect bugs, vulnerabilities, and errors in your code and how to clean up your code to make it safe for production environments.  

Playing with SonarQube  

In this GitHub project, you’ll find an example of code written in JavaScript. The goal: to show you how to incorporate SonarQube into your development workflow. The repository contains two main folders (sources and tests) so, in this way, you can know the percentage of our code that is being covered by the tests. 

This project also includes a sonar-project.properties file where there are some configuration parameters needed to configure SonarQube like username, password, language, etc. 

First, run the scanner inside the project folder, that way the first scanner is launched and you can check the results in the web interface. 

sonar-scanner 


As you can see in the above screenshot, the current code has zero bugs, zero vulnerabilities and six code "smells". 

Modify the source code in order to introduce one bug and one vulnerability. This time it is intentional, but in daily work problems like this can arise without you realizing. 

Run the scanner again:

sonar-scanner 

As expected, a new bug and vulnerability appear. Check the analysis again to see the changes we made: 


A new section appears on the right-hand side of the screen (highlighted in yellow). SonarQube handles two states: the current state (in white) and the latest changes. 

As you can see in the screenshot, the changes introduced in the last scan have added one bug and one vulnerability. SonarQube evaluates the quality of each section with a score based on different parameters, A being the best state. In this case, introducing the bug has caused the “Bugs” section to pass from A to C and the “Vulnerabilities” section from A to B. 

You can set the “Leak Period” to determine how you want to make the comparison: by time or between each scanner execution. 

Let’s see in detail the "Coverage" section: 38.1% is the global test coverage (as you can see in the GitHub repository, I have tests for some files, but not for all of them). In the yellow section, you can see the coverage for the newly added lines. Previously, we introduced some new lines in order to add errors but we didn’t create any test for these new lines, so the new test coverage is 0%. Also, by clicking on Coverage, you can see more information about the coverage, for example, coverage by file, number of covered lines, etc. 


With this quick and simple analysis (you only have to execute one command) you will be able to prevent errors like these arising in production environments, keeping the code safe and complying with best practice and quality standards. In the following iterations we will work towards the goal of zero bugs, vulnerabilities, and code "smells". We might also work on getting 100% of our code covered by the tests. 

Once we have my code in this state, it is very simple to see if the changes made have introduced some kind of error or bad practice. 

How to squeeze SonarQube 

As you saw in the previous section, it is quite simple to keep your code in good health. But, there is more to discover. SonarQube has a lot of cool integrations. 

Analysis Methods

You can choose between the following analysis methods: 
  • SonarQube scanner for MSBuild: Launch analysis of .Net projects 
  • SonarQube scanner for Maven: Launch analysis from Maven with minimal configuration 
  • SonarQube scanner for Gradle: Launch Gradle analysis 
  • SonarQube scanner for Ant: Launch analysis from Ant 
  • SonarQube scanner for Jenkins: Launch analysis from Jenkins 
  • SonarQube scanner: Launch analysis from the command line when none of the other analyzers is appropriate 

Plugins

In addition, SonarQube has an Update Center with a variety of plugins organized into different categories, some useful plugins are: 
  • Code Analyzers 
    • SonarCFamily C/C++ 
    • SonarPHP 
    • SonarJS 
    • SonarWeb 
    • SonarJava 
    • CSS 
  • Integration
    • GitHub Plugin: Analyzes pull requests, and points out the issues as comments.
    • Google Analytics: Adds the Google Analytics tracking script to the SonarQube web application.
    • SCM Engines 
    • Mercurial: Adds support for Mercurial. 
    • Git: Adds support for Git. 
    • SVN: Adds support for Subversion. 
  • Authentication & Authorization
    • GitHub Authentication: Enables user authentication and Single Sign-On via GitHub. 
    • GitLab Authentication: Enables user authentication and Single Sign-On via GitLab. 
    • Google Authentication: Enabled delegation of user authentication to Google. 
Happy (and safe) coding!