Wednesday, May 15, 2019

VMware to acquire Bitnami

We are proud and excited to announce that VMware is acquiring Bitnami!

This is fantastic news for our users and partners. We will continue to deliver the Bitnami catalog of apps that you know and love, across all the platforms we currently support, including all the major cloud vendors. Joining forces with VMware means that we will be able to both double-down on the breadth and depth of our current offering and bring Bitnami to even more clouds as well as accelerating our push into the enterprise.

We built Bitnami from zero to a significant user base, with all of the major cloud vendors as customers. We primarily bootstrapped the business, having raised just  $1.1M from YCombinator and a handful of great angels, when we were already profitable. We have a great team, great products, and a great business. Why join forces with VMware? This was actually an easy decision and has to do with our shared vision for the future.

Our mission at Bitnami is to make awesome software available to everyone, everywhere. There is a lot of great software out there, much of it open source, that is out of reach of many developers and system administrators because it is too complex to set up and maintain.

Our focus is to make that software accessible to the largest number of users and developers possible. We started with native installers that ran on Windows, Linux, and macOS. After a few clicks, users could get a complete web application such as WordPress up and running in their laptop without having to manually install and configure Apache, MySQL, PHP, and supporting libraries. Over time, we expanded to VMs, cloud images, and containers while maintaining our focus on keeping applications easy to use, secure, and up to date.

Over the past years, we expanded our focus to help enterprises use Bitnami in production, often as part of a migration of their application to the cloud or their adoption of Kubernetes. We realized that, if we wanted to continue to grow, we would have to raise money, as building an enterprise salesforce is not easy to do when you are bootstrapped. This was a decision we didn’t take lightly, but not raising money had its own risks, including potentially missing a window of opportunity in the industry.

As part of the fundraising process, we were approached by several vendors in the space to make strategic investments or, in some cases, join forces. While this was not our original goal, as part of the conversations that we had during this process, we realized that VMware would be the ideal partner for us. We both believe in a Kubernetes and multi-cloud future. We both share large enterprise customers, including cloud service providers. We both are building products and services to help companies navigate this multi-platform, multi-vendor world with a focus on enterprises. VMware already has more than 500,000 customers globally!

What really sealed the deal for us was getting to know the team at VMware: smart, talented and driven. This positive personal chemistry was tremendously important to us as founders. When you have been building a company over a decade, you want to make sure it is the right home for the team and product.

So what does it mean for you, our users and partners? In a way, nothing is changing. We will continue to develop and maintain our application catalog across all the platforms we support and even expand to additional ones. Additionally, if you are a company using Bitnami in production, a lot of new opportunities just opened up. Get in touch!

Startups are a team sport. Bitnami has become what it is today thanks to the hard work of an incredible team that we have assembled over the years and that has stuck with us through all the ups and downs of the startup rollercoaster. For some of them, this was their first job out of college, and they have grown professionally over the years to become great managers and engineers, alongside the company itself. We cannot think of a better way to continue their contributions and career growth than as part of VMware, an industry leader.

We also want to take this opportunity to thank those who believed in us from the beginning. We were fortunate to have an incredible group of investors and advisors who have supported us along the way, and would like to especially thank the following people for their unwavering support: Jesus Blanco, Armando Pauker, Peter Courture, Joe Brescia, Clemens Buss, Beau Vrolyk, Elad Gil, Othman Laraki, Diego Basch, Jun Li, Eric Hahn, Ullas Naik, Hiro Maeda, Mike Olson, Michael Hughes, Marten Mickos, Michael Levit, Ali Rowghani, and the entire Y Combinator team.

Erica, Daniel, and the Bitnami team

MDS attacks against Intel CPUs and Zombieload vulnerability

Latest updates

[UPDATE 2019-05-19]

- Bitnami has now released all the images with the new kernel available for Debian, Ubuntu and Oracle Linux in the Bitnami Launchpad for Oracle Cloud and the Oracle Cloud Marketplace.

[UPDATE 2019-05-17]

- Bitnami has now submitted all the VMware affected images with the new kernel. Updates are being propagated to the VMware Marketplace

[UPDATE 2019-05-16]

- Bitnami has now released all the images with the new kernel available for Debian 9 in the Bitnami Launchpad for AWS Cloud. Updates with the new kernel available for Ubuntu 16.04 are being propagated to the AWS Marketplace.

- Bitnami has now released all the images with the new kernel available for Ubuntu 16.04 in the Bitnami Launchpad for Microsoft Azure. Updates are also being propagated to the Azure Marketplace.

- Bitnami has now released all the images with the new kernel available for Debian 9 in Bitnami Launchpad for Google Cloud Platform. Updates are being propagated to the Google Marketplace.

- Bitnami has now released all the virtual machines (OVA and VMDK format) with the new kernel available for Debian 9. They are available at

- If you are running a native installer on a bare metal server, you should update the kernel in your host as well as install the Intel microcode firmware. This package is available in the “contrib” and “non-free” repositories that you should previously enable in your distro.


On May the 14th, security researchers have disclosed a new attack impacting the speculative execution process. This is named as Microarchitectural Data Sampling (MDS) attacks and with Zombieload Vulnerabilities being considered the most dangerous of them. 

Similar to the previous Meltdown and Spectre attacks, it can effectively break all privacy protections that exist between apps. An attacker could allow data in the CPU’s cache to be exposed to unauthorized processes. It could use these flaws to read memory from a virtual or containerized instance or the underlying host system.

Bitnami team is working on updating all affected Virtual Machines and Cloud Images available through Bitnami, for all of our cloud provider partners. This will ensure that all new launches will be secured against these issues.

If you already have a running server (virtual machine) or if you have a Bitnami stack installed on your computer, you will need to update the operating system on your own.

Once a new, patched kernel is available from the operating system vendor, you can update it by following these instructions (depending on your distribution / operating system):

- Ubuntu / Debian
sudo apt-get update && sudo apt-get dist-upgrade 
- Oracle Linux, Red Hat, CentOS, and Amazon Linux
sudo yum update 
- Windows / OSX
Update your system packages when the operating system suggests to. Enable the "Check for updates" option in Windows in order to get the latest updates and patches.

Once you have completed the steps above, you will get the fixed version of the kernel / operating system after rebooting your server. The versions that fix these vulnerabilities are the following:

- Ubuntu 16.04: 4.4.0-148-generic
- Ubuntu 16.04 for Azure: 4.15.0-1045-azure
- Debian 9: 4.9.168-1+deb9u2
- Oracle Linux 7: 4.1.12-124.26.12.el7uek or 4.14.35-1844.4.5.2.el7uek
- Red Hat: 3.10.0-957.12.2.el7
- CentOS: 3.10.0-957.12.2.el7
- Amazon Linux: 4.14.114-83.126.amzn1

If you have any questions about this process, please post to the Bitnami community support forum. We will be happy to help!

For further information about these vulnerabilities, check the frequently asked questions page at the official Zombieloadattack website:

Tuesday, May 14, 2019

Portable, Universal Single Sign-On for Your Kubernetes Clusters

Hi! I am Miguel, a software engineer at Bitnami and core contributor to open source Kubernetes-related projects like Helm, Monocular or Kubeapps.

Kubeapps is an application dashboard for Kubernetes. A web user interface that allows users to deploy and manage Kubernetes applications or interact with the Kubernetes Service Catalog.

Until now, our users needed to manually log in by providing the token associated with a Kubernetes Service Account previously created by a cluster operator. These manual steps had an impact in user experience and adoption.

We asked the community how we could improve this process and the most requested feature was Single Sign-On (SSO) support.

Kubeapps is not the only application in this scenario, any other application that talks to the Kubernetes API directly, such as kubectl or the Kubernetes Dashboard, belong to this category too. That’s why we decided to publish our research so other projects in the Kubernetes community can leverage our findings.

Why Single Sign-On?

To kick off our project, we looked at the main authentication methods in Kubernetes and analyzed four main attributes:
  • Can a user self-serve credentials or it requires the intervention of a cluster operator?
  • Can those credentials be rotated?
  • Can they be revoked?
  • What’s the user experience during both the provisioning and the usage of those credentials?
The results based on our experience are:

In our experience, using X509 Client Certs required a cluster operator team to verify the user identity, craft a certificate and share it securely. This AuthN mechanism is not great in terms of rotation/revocation either since all the certs crafted from the common CA needs to be revoked in order to revoke a single user.

Static Token/Service account and basic auth share similar properties. Self-serve is not generally possible but per-user rotation/revocation is possible. Although, in some cases, it requires restarting the Kubernetes API server.

Lastly, we looked at Single Sign-On powered by OpenID Connect. Once this AuthN mechanism is in place, users can self-serve. It has built-in credential rotation via refresh tokens. Revocation has the small caveat of the token being valid during its lifespan which depends on the Identity Provider.

The UX section is colored in green not only because of the usability enhancement from the User point of view, but also from the Cluster Operator’s who do not need to craft, rotate or transfer credentials anymore and just delegate all that to a third party Identity Provider (IdP).

SSO Support - Simple Scenario

After validating that, Single Sign-on seemed a good solution for our needs. We decided to go ahead with the implementation, which seemed straightforward from our research.

We will put an OpenID-Connect proxy in front of our application, configured to trust the same OIDC IdP than the Kubernetes API server.

The solution could look something like this:

In the example above, we are putting a proxy in front of our application that will take care of 1) intercepting and enforce authentication by performing the required Oauth2 dance and 2) inject a new set of headers including the user info in the form of a JSON Web Token (JWT).

For this solution to work, both the Kubernetes API server and the OIDC-proxy are configured to trust the same OIDC identity provider, and this is only possible if the k8s API server is customizable, which is not always the case.

SSO Support - Complex Scenario

K8s API server customization is not available in all providers, which made it our biggest challenge. Some managed services like Google’s GKE or AWS’ EKS do not support customizing the OIDC settings, while others like Azure’s offering just expose their own identity providers. 

We had to ask ourselves “How can we offer a solution that works in all platforms? We brainstormed a couple of solutions, from translating OIDC tokens to service accounts via a custom controller to using K8s impersonation.

Impersonation is a feature in Kubernetes that allows a user to act on behalf of another user or group as long as it has permissions to do so.

Impersonation can be performed via custom headers or even directly via kubectl. In the following example we are telling Kubernetes that we want to impersonate the “FooUser” from the “kubeapps-user” group. Then, Kubernetes will make sure my user can impersonate the FooUser and then FooUser can get pods in the current namespace.

$ kubectl get pods --as FooUser --as-group kubeapps-user

By leveraging impersonation, we could put an additional proxy that will take a valid (but not understood by the k8s API) server Id_token (JWT) and transform it into impersonation headers that Kubernetes will understand. 

By placing this proxy that leverages a k8s native feature like Impersonation between our application and the API server, we are able to offer a Single Sign-On experience that will work in all platforms.

If you want to learn more about these workarounds and see them in action, I’ll be speaking at Kubecon EU on May 21st, come by to say hi! See you in Barcelona!