Meet the team: Felipe

The Bitnami team is a diverse group of talented people distributed all over the world. Get to know them better through this series of blog posts.

Based in Madrid, Felipe works remotely as a Kubernetes Engineers on our Kubernetes squad.

A Brief Bio

I was born and raised in Madrid. At the age of 8, I saw a Sinclair ZX Spectrum in a small shop near my house and I fell in love with it. I used it mostly to play games and connected to an old black and white TV. After playing with the system more, I started to get curious to about how it worked.

At that time there weren’t many computer magazines, but the few that did exist talked about games and how to hack games (do you remember poke and randomize usr?). Eventually, I was lucky enough to have my parents buy me an Amstrad CPC 6128, which is when I started to learn how to program. I even wrote a small stocks application for my father’s business, although he never got to use it because he preferred to run his business the old way. And then, one Christmas, after the 3 Kings Night, I received my first PC with 640KB of memory and a 20MB hard-disk drive and one 5 ¼” floppy drive. 

Fast-forward into the future, my life revolved around computers. I attended university in 1992 to study Computer Science, but quit soon afterwards and started to work for a financial company in 1997. Later on, I switched careers and moved into consulting and training to join Google in Zürich in 2006, then Telefónica in 2013 and now Bitnami in 2018.

I still remembers those days when there was no Internet, games were bought or traded with friends, and magazines mostly focused on low-level assembly or video games. Then, the modems (US Robotics) came. First 9,200 bauds, then 14,400, then 28,800 and finally 56k, using a POTS which I shared with my parents. There were so many times when my dial-up connection broke because my father tried to speak on the phone while I was using the modem. Then, circa 1992, I got my first 256 kbps ADSL connection, which changed everything. Not just because of the speed, but because of the price. The days of using CompuServer or the BBS were behind us. Then came Linux. I switched from Windows to Linux when the only Linux distro was the SLS. Then, Slackware, then RedHat, then I bought a Mac and I have been using macOS since then.

Why you joined Bitnami and what excites you about working here? 

I switched because I want to work on bleeding-edge technology like Kubernetes, be part of a great community of engineers, and contribute to open-source. During the interview process, the team showed me of how cool Bitnami was and I was convinced that this was the place I needed to be. :-)

What are you working on?

I am one of the core engineers working on Bitnami Kubernetes Production Runtime, which adds additional functionality to an existing Kubernetes cluster. For instance, logging and alerting, ingress routing, automatic DNS name publishing for Kubernetes services, transparent TLS termination for HTTP/S traffic using Letsencrypt, etc.

This framework leverages existing open source components, maintained and packaged by Bitnami, with security and ease of use in mind, plus accompanying command-line tools and documentation to deploy and use.

If you'd like to be notified when it is released, sign-up here. 

Enjoying the outdoors with his family

 What do you like to do for fun?

I enjoy spending time with my family and friends, traveling to new (and not so new) places, and going hiking to the mountains.

Interested in working with Bitnami and Felipe? Apply for one of our open positions!

L1 Terminal Fault: Privileged memory access vulnerability in Intel CPUs

Update (08/22)

The regressions affecting Ubuntu 14.04 have been fixed in kernel 3.13.0-116.163. Please check below for instructions on how to upgrade the Ubuntu 14.04 kernel.

Update (08/21)

Bitnami has now released all the Debian based images with the new kernel available. Updates are being propagated to the Bitnami Launchpads and the different Cloud Platforms.

Update (08/20)

Debian stretch's packages have been published to fix the security issue described here. The Bitnami team is working on publishing our solutions as soon as possible. If you have a running Debian instance, please upgrade the packages by following the documentation included below. 

Update (08/17)

A regression has been detected in Ubuntu 14.04 in certain instance types, which causes a kernel panic during boot time. More details can be found in Launchpad. Users are advised not to upgrade the kernel in Ubuntu 14.04 until a fix is released.

For users running other operating systems, it is highly recommended to create a full backup of the disk before upgrading the kernel version.

Update (08/16)

Bitnami has now released all the Ubuntu, Red Hat, CentOS and Oracle Linux based images with the new kernel available. Updates are being propagated to the Bitnami Launchpads and the different Cloud Platforms.

Description

On August 14th 2018, three vulnerabilities affecting x86 processors manufactured by Intel were disclosed:

• CVE-2018-3646 [1]
• CVE-2018-3615 [2]
• CVE-2018-3620 [3]

The security issue is referred to as L1 Terminal Fault (L1TF) by the industry, and as “Foreshadow” by the security researcher.

The L1 Terminal Fault security issue exploits critical vulnerabilities in modern processors. It allows attackers to access sensitive data in a personal computer or third party clouds.

With L1TF, a malicious program can exploit an operating system’s Page Table by reading the data referenced to the virtual memory, before the CPU is able to confirm that a page table entry is valid. Once the Page Table Entry is set as invalid, the CPU signals a Terminal Fault to the OS.

L1 Terminal Fault affects the following systems:

• Operating systems running virtual machines.
• Cloud instances: Depending on the cloud provider's infrastructure, it might be even possible to steal data from other customers.

Our team is working on updating all the affected Virtual Machines and Cloud Images available through Bitnami in all our cloud providers. This will ensure that all new launches will be secured against this issue.

At this time, there are patches available for the following operating systems:

• Debian
• Ubuntu
• Oracle Linux
• Red Hat Enterprise Linux
• CentOS
• Amazon Linux

If you are running a Bitnami stack, or you have any running server or virtual machine, we encourage you to apply these patches immediately in order to avoid exploitation of this security issue. You need to update the operating system yourself.

In order to update your operating system, you must follow the instructions below (depending on your distribution or operating system):

• Debian 9, Ubuntu 14, Ubuntu 16 and 18: Create a full backup of the disk, and then execute the command below.

sudo apt-get update && sudo apt-get dist-upgrade

• Oracle Linux, Red Hat, CentOS and Amazon Linux: Create a full backup of the disk, and then execute the command below.

sudo yum update

• Windows and macOS:

Update your system packages when the operating system suggests it. Enable the "Check for updates" option in Windows to get the latest updates and patches.

Once you have completed the steps above, you will have the updated kernel/operating system version after rebooting your server. If you are running on a Linux server, execute the following command to restart it:

sudo shutdown -r now 'Kernel upgrade requires reboot'

NOTE: If, after rebooting, you cannot access the instance via browser or SSH, it is highly likely that the cloud provider assigned a new dynamic IP address to your instance. In this case, enter your cloud provider administration panel to check the new IP address.

If you have any questions about this process, please post to our community support forum and we will be happy to help!

Check out the official Foreshadow site [4] and the RedHat article explaining the attack [5], for more information.

More information can be found in the following links:

• [1] https://access.redhat.com/security/cve/cve-2018-3646
• [2] https://nvd.nist.gov/vuln/detail/CVE-2018-3615
• [3] https://access.redhat.com/security/cve/cve-2018-3620
• [4] https://foreshadowattack.eu/
• [5] https://www.redhat.com/en/blog/understanding-l1-terminal-fault-aka-foreshadow-what-you-need-know

Self-service Apps - Automating the Packaging-to-publishing Experience for Kubernetes with Bitnami Stacksmith and Kubeapps

Do you have the need to make containerized applications available to your internal teams? Here is a great way to accomplish not only that, but also automate the workflow associated with packaging, launching, and updating these applications. Learn how combining Bitnami Stacksmith and Kubeapps can provide a marketplace experience from within your current Kubernetes cluster. You can use this one simple workflow to package, deploy and maintain the applications you have developed, the commercial software you have customized, or the older applications you are migrating.

Stacksmith provides automated application packaging and ongoing maintenance of your applications. Kubeapps provides a complete application delivery environment that empowers users to launch, review and share applications. Together they offer a powerful packaging-to-launch experience for Kubernetes applications.

We created a brief how-to video that shows you how easy it is to integrate both Stacksmith and Kubeapps with your preferred artifact repository (such as JFrog Artifactory or ChartMuseum). Doing so streamlines and automates the packaging, updating, and publishing of your applications to a Kubernetes cluster.

In the video, we demonstrate the following:

• Use Stacksmith to package a .Net Core application for Kubernetes
• Once packaged, Stacksmith pushes the container image to the registry and the Helm chart to the artifact repository
• Kubeapps scans the artifact repository and makes the application deployable with just a few clicks
• The application gets launched via Kubeapps
• Over time, components of your application will need updating (security and package updates are tracked by Stacksmith). Re-package your application with Stacksmith
• Stacksmith pushes the updated container image to the registry and the Helm chart to the artifact repository
• Kubeapps fetches the new version of your application

                               

Besides the convenience and automation provided by integrating Stacksmith and Kubeapps with the repositories that store and verify assets, are there other benefits? Yes - doing so provides an end-to-end solution that maintains trust between development, security and operations. Now you can ensure that your code, dependencies, security policies, operations scripts and orchestration come from a trusted repository, and that they will get securely and continuously packaged.

Generate, maintain, store and present - trusted applications from trusted artifacts

And Bitnami can deliver these benefits regardless of your level of DevOps sophistication, whether you are using only basic tools or have a fully automated process in place. It is easy to integrate the packaging, distribution, and maintenance capabilities we are talking about here into any existing tool chain or DevOps process.

Learn more - check out the video and visit the Stacksmith and Kubeapps pages.

Enterprise CI / CD Integration and Application Packaging

By Matt Small, Head of Customer Success 

Application Packaging is probably not something you’re familiar with hearing about as part of a “CI/CD process.” Most companies that are working towards full DevOps automation feel that as long as the Dev side and the Ops side are automated independently, tying those two processes together is all that’s needed. However, that is a challenging problem when you’re dealing with a heterogeneous collection of team-selected tools in your tool chain. Enterprises that encourage Development and Operations teams to select the best tools for the job are getting stuck trying to implement policies and best practices that can handle that heterogeneity. This heterogeneity in tooling and the rapid pace at which that tooling is changing also means the beginning of the end for the full-stack developer in the Enterprise. It’s just not feasible for someone to know it all well enough to enforce it all.

New, container-centric CI tools that leverage the relative simplicity that container abstraction provides try and merge the two entirely: a check-in of code will automatically deploy that code. While that’s the ideal approach to automation, it ignores both legacy premise-based infrastructure as well as evolving trends in the industry toward PaaS and FaaS. As new applications are built and as old ones are modernized, they too will be heterogeneous in nature and designed to take advantage of the best-fit cloud services.

That’s a lot of of technical complexity and distributed tribal knowledge that must be managed just to answer the questions “what is this application, how does it run, and is it up to date?” 

A logical place to answer that question is in the Application Package. If done correctly, Enterprises now have a way to define their infrastructure in an application-centric way, inclusive of the code, the dependencies, the configuration and the orchestration required to deliver that application. This is how Bitnami Stacksmith handles application packaging. Developers, Security and Operations continue to use their tooling of choice to trigger the process, and Application Packaging automation pulls in the required Artifacts and Assets from their trusted sources to create deployment ready outputs that can be picked up downstream.

Examples of ways to integrate application packaging and maintenance with your CI / CD tools

In practice, Developers push their code to their CI tool of choice and may also contribute their application dependencies and configuration logic as scripts in their source control management tool of choice. Information Security teams maintain OS hardening process and other security policies as scripts or orchestration templates. Operations contributes best practices, reference deployment automation, and prefered cloud service configurations and defines their preferred Template and image output formats. A new contribution from any team triggers a repackaging process, ensuring that the resulting Templates, Images, Containers and PaaS integrations are continuously maintained and up-to-date.

In addition to team-provided changes, updates and changes to the OS and application system packages, dependencies, and any related CVEs should also prompt a repackaging. This tightens the refresh cycle and ensures that the process can be made continuously secure.

The package is an immutable and versionable point in time in an application’s lifecycle. It promotes best practices in testing, providing the ability to launch and test against all components of the application as a complete package. It facilitates in-place application upgrades using native cloud orchestration tooling as well as leveraging blue-green release process or canary deployments by recreating net-new deployments for a full refresh. It also simplifies roll-back, allowing previous application packages to be completely redeployed.

Logging the image creation process gives you a detailed record of the event and every step of the process, as well as a manifest of everything that was packaged into the images or containers and is now immutable. These logs and manifests provide important assurances to the organization: assurance that everyone’s contributions are verifiably included, that the IT infrastructure is auditable, and that no affected library is left unpatched in the event of a critical vulnerability.

As the cloud continues to rapidly evolve with more services and functions, as tooling continues to evolve with new strategies and optimized approaches, the Application Package remains at the center of the DevOps handoff, providing the needed flexibility for application and infrastructure stakeholders to leverage their own best-fit tools and services while enforcing the policies and best practices that are important to them.

Want to learn more? Watch the recording of our latest demo here.  

SegmentSmack: Linux Kernel TCP Vulnerability

[UPDATE 2018-08-08]

The Bitnami Team is happy to announce that the Bitnami Launchpad images for AWS, Azure, Google and Oracle (Debian) were updated with the security fix. We also updated the AWS Community and the Bitnami Cloud Hosting Debian images. We continue tracking the packages of the rest of the platforms to publish them as soon as possible.

If you are using a Bitnami Virtual Machine, we also updated those images using the new packages.

[UPDATE 2018-08-07]

Updated information of the affected kernels and methods to patch the images

----

A new security vulnerability in the Linux Kernel known as SegmentSmack (CVE-2018-5390) was publicly disclosed today. It allows attackers to trigger the most resource-intensive code paths for TCP stream reassembly with low rates of specially crafted packets, leading to a remote denial of service. 

The affected versions of the Linux kernel are versions 4.9+ and maintaining the denial of service condition requires continuous two-way TCP sessions to a reachable open port.

We believe it is of the utmost importance to quickly address any security issues in applications distributed by Bitnami. For that reason, our team is working to update all of the affected images available through Bitnami as quickly as possible.

If you have any existing running server (virtual machines) 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 the instructions below

Affected Platforms 

To check if your system is not vulnerable, execute the command below:

    uname -a

The output you obtain after running the above command indicates the version of the kernel package you currently have installed and running on your system. Only versions 4.9+ of the Linux kernel are vulnerable, find in the list below which are the kernel versions you should have to make sure that your system is not vulnerable:

Debian 8 (Jessie)
Debian Jessie kernel should be equal or greater than 3.16.57-2.

Debian 9 (Stretch)
Debian Stretch kernel should be equal or greater than 4.9.110-3+deb9u1.

Ubuntu 16.04 in Azure
Ubuntu 16.04 kernel version in Azure should be equal or greater than 4.15.0-1019-azure.

Oracle Enterprise Linux
This distribution is not affected.

Other distributions: RHEL, CentOS, Ubuntu 16.04 in AWS, ...
There is not any new package for these Linux distributions at the moment of writing this.

How To Patch It 

Debian / Ubuntu

    sudo apt-get update && sudo apt-get dist-upgrade

Oracle Enterprise Linux

This distribution is not affected.

Other distributions: RHEL, CentOS, Ubuntu 16.04 in AWS, ...

There is not any new package for these Linux distributions. (Keep checking back for updates!)

Reboot your server/operating system after running the commands.

Once you have completed the steps above, you will have the fixed version of the kernel/operating system running on your server. If you have any question about this process, please post it in our community support forum. We will be happy to help!

Announcing New Stacksmith Features - Git Repository Support, Customized Deployment Templates, and CLI beta

Since launching Stacksmith this spring, we have been busy collecting feedback from our early enterprise customers in order to prioritize new feature developments appropriately. One of the consistent pieces of feedback we heard, whether they’re using Stacksmith to move-and-improve existing applications to the cloud, or upgrading their software delivery pipeline for containerization, has been the need for Stacksmith to work seamlessly with existing systems, tools, and workflows. We’re happy to announce several new features now available to address these requests.  Here is a brief overview of the most important improvements.

Oh, and if you are interested in getting a personalized walkthrough of these new features and / or Stacksmith in general, please email our Customer Success team at customersuccess@bitnami.com and we will be happy to set up some time with you.

Integration with Git repositories

Developers typically use a version control system as a 'source of truth' for their application code, and GitOps encourages operations, security, and support teams to follow similar practices. Now, Stacksmith aligns with this best practice via its support for Git repositories.  This new feature enables application runtime configurations and app customization scripts to be stored and tracked from a Git repository.

This means you no longer need to upload your build and configuration scripts manually to Stacksmith. You can now simply place them in your repository, provide the repository URL to Stacksmith, and Stacksmith will fetch them from there.

To make things even easier, Stacksmith continuously monitors your repository, and will show when and what changes have been made.

For example, if you need to make an OS configuration change, add new application dependencies, or modify your boot logic for your application, all you need to do now is update the script and check it in to Github.

This new feature is a another great example of how Stacksmith makes it easy to keep your applications up to date and secure while further automating your code to cloud pipeline!

Stacksmith currently supports public Git repositories with this feature. If you would like to connect to a private repository that requires authentication, please contact us at customersuccess@bitnami.com.

Customizable deployment templates

The Stacksmith packaging process produces not only a VM or container image, but also the deployment template you will need to deploy your image on your target platform. Stack templates are the place in Stacksmith where the policies that will end up in the deployment template are defined.

Stacksmith provides a set of default stack templates that cover most common scenarios, but some companies want the ability to customize these templates to their specific requirements.  Now you can.

The Stacksmith administrator can now create customized stack templates, and make them available  for others to use in the packaging process.

This gives the operations team a tremendous amount of flexibility in defining what the final deployment template will include. For example, it lets them add extra options at deploy time, define additional services like load balancing for the application, establish that the application should be exposed on a public IP, specify that a specific database type should be used, or pass additional configuration definition across to the application.

This new feature enables your operations team to further ensure your specific policies and best practices are included in the application packaging process.

Stacksmith CLI - In Beta

We’ve released an important improvement to the Stacksmith API in the form of a documented CLI. These tools are designed to make it easy to link Stacksmith to an existing CI system such as Jenkins, TeamCity or CircleCI, and enable teams to get deployable artifacts whenever a change in their application code is landed.

In combination with the release of the CLI, we are also implementing support for long lasting authentication tokens. Combined, these improvements enable you to embed and automate Stacksmith's processes into your existing pipeline. Using this CLI, you can enable automatic application rebuilds when dependencies or application code is changed.   

You can find this CLI, along with documentation and a sample integration, at https://github.com/bitnami/stacksmith-cli. We’re releasing the CLI in beta form at this point so we can better understand your use-cases and integration challenges. Issues and PRs are welcome on Github!

Try out these new features on Stacksmith today, or reach out to our customer success team at customersucess@bitnami.com for a customized walkthrough.