Tag Archives: OSS

Google joins the Open Source Security Foundation

In modern software development, much of the code developers use originates outside their organization and is open source. While the cloud and internet ecosystem depends on an open source foundation, the sheer scale and dependency chain of the libraries and packages we all use makes it difficult to validate and verify the origin of the code you’re ingesting; that it’s up to date on recent patches, and coming from projects following security best practices. To continue deriving benefits from open source, we need to ensure that as a community we are building on the strongest possible foundation. 



At Google, security is always top of mind, and we have developed robust systems and security tools—including open source ones—to protect our internal systems and our customers. We believe the more we share what we’ve learned about open source security, and the more we work with those who face similar challenges, the more we can improve the state of open source security for everyone.

We’re happy to announce that Google is joining the Open Source Security Foundation (OpenSSF) to work alongside the broader industry on this journey of improving the state of security of open source projects we all depend on. Google has key areas in open source security we want to work on, and we’re excited to share our ideas with the OpenSSF community and work together. Some of our key areas are:

Shared schemas and metadata that enable automation for enforcing security best practices along the entire software supply chain.

Dependency management and risk assessments through tooling and data. We want to make it easy to map vulnerabilities back to specific versions of code that are affected and take action.
Verifiable builds through trusted build systems so that we know artifacts haven’t been tampered with. The Tekton project has been exploring this idea, and we’re excited to share some of these ideas with OpenSSF.

A developer identity system to help associate code changes back to their original author and help code reviewers have developer authentication as part of their commit and PR review process.

Securing critical OSS projects and helping projects respond to vulnerabilities. If you’re a maintainer who’s interested in getting help with vulnerability response or security engineering efforts, watch this space!

Security challenges are never going to disappear, and we must work together to maintain the security of the open source software we collectively depend on. If you're interested in getting involved in the OpenSSF initiatives, visit openssf.org or OpenSSF on GitHub.You can be a part of how the OpenSSF serves the open source community and the world!

By Kim Lewandowski, Product Security Team, and Dan Lorenc, Infrastructure Security Team, Google

Kpt: Packaging up your Kubernetes configuration with git and YAML since 2014

Kubernetes configuration manifests have become an industry standard for deploying both custom and off-the-shelf applications (as well as for infrastructure). Manifests are combined into bundles to create higher-level deployable systems as well as reusable blueprints (such as a product offering, off the shelf software, or customizable starting point for a new application).

However, most teams lack the expertise or desire to create bespoke bundles of configuration from scratch and instead: 1) either fork them from another bundle, or 2) use some packaging solution which generates manifests from code.

Teams quickly discover they need to customize, validate, audit and re-publish their forked/ generated bundles for their environment. Most packaging solutions to date are tightly coupled to some format written as code (e.g. templates, DSLs, etc). This introduces a number of challenges when trying to extend, build on top of, or integrate them with other systems. For example, how does one update a forked template from upstream, or how does one apply custom validation?

Packaging is the foundation of building reusable components, but it also incurs a productivity tax on the users of those components.

Today we’d like to introduce kpt, an OSS tool for Kubernetes packaging, which uses a standard format to bundle, publish, customize, update, and apply configuration manifests.

Kpt is built around an “as data” architecture bundling Kubernetes resource configuration, a format for both humans and machines. The ability for tools to read and write the package contents using standardized data structures enables powerful new capabilities:
  • Any existing directory in a Git repo with configuration files can be used as a kpt package.
  • Packages can be arbitrarily customized and later pull in updates from upstream by merging them.
  • Tools and automation can perform high-level operations by transforming and validating package data on behalf of users or systems.
  • Organizations can develop their own tools and automation which operate against the package data.
  • Existing tools and automation that work with resource configuration “just work” with kpt.
  • Existing solutions that generate configuration (e.g. from templates or DSLs) can emit kpt packages which enable the above capabilities for them.

Example workflow with kpt

Now that we’ve established the benefits of using kpt for managing your packages of Kubernetes config, lets walk through how an enterprise might leverage kpt to package, share and use their best practices for Kubernetes across the organization.


First, a team within the organization may build and contribute to a repository of best practices (pictured in blue) for managing a certain type of application, for example a microservice (called “app”). As the best practices are developed within an organization, downstream teams will want to consume and modify configuration blueprints based on them. These blueprints provide a blessed starting point which adheres to organization policies and conventions.

The downstream team will get their own copy of a package by downloading it to their local filesystem (pictured in red) using kpt pkg get. This clones the git subdirectory, recording upstream metadata so that it can be updated later.

They may decide to update the number of replicas to fit their scaling requirements or may need to alter part of the image field to be the image name for their app. They can directly modify the configuration using a text editor (as would be done before). Alternatively, the package may define setters, allowing fields to be set programmatically using kpt cfg set. Setters streamline workflows by providing user and automation friendly commands to perform common operations.

Once the modifications have been made to the local filesystem, the team will commit and push their package to an app repository owned by them. From there, a CI/CD pipeline will kick off and the deployment process will begin. As a final customization before the package is deployed to the cluster, the CI/CD pipeline will inject the digest of the image it just built into the image field (using kpt cfg set). When the image digest has been set, the CI/CD pipeline can send the manifests to the cluster using kpt live apply. Kpt live operates like kubectl apply, providing additional functionality to prune resources deleted from the configuration and block on rollout completion (reporting status of the rollout back to the user).

Now that we’ve walked through how you might use kpt in your organization, we’d love it if you’d try it out, read the docs, or contribute.

One more thing

There’s still a lot to the story we didn’t cover here. Expect to hear more from us about:
  • Using kpt with GitOps
  • Building custom logic with functions
  • Writing effective blueprints with kpt and kustomize
By Phillip Wittrock, Software Engineer and Vic Iglesias, Cloud Solutions Architect

Paving the way for a more diverse open source landscape: The First OSS Contributor Summit in Mexico

“I was able to make my first contribution yesterday, and today it was merged. I'm so excited about my first steps in open source", a participant said about the First Summit for Open Source Contributors, which took place this September in Guadalajara, México.
How do you involve others in open source? How can we make this space more inclusive for groups with low representation in the field?

With these questions in mind and the call to contribute to software that is powering the world's favorite products, Google partnered with Software Guru magazine, Wizeline Academy, OSOM (a consortium started by Googler, Griselda Cuevas, to engage more Mexican developers in open source), IBM, Intel, Salesforce and Indeed to organize the First Summit for Open Source Contributors in Mexico. The Apache Software Foundation and the CNCF were some of the organizations that sponsored the conference. The event consisted of two days of training and presentations on a selection of open source projects, including Apache Beam, Gnome, Node JS, Istio, Kubernetes, Firefox, Drupal, and others. Through 19 workshops, participants were able to learn about the state of open source in Latin America, and also get dedicated coaching and hands-on practice to become active contributors in OSS. While unpaid, these collaborations represent the most popular way of learning to code and building a portfolio for young professionals, or people looking to do a career shift towards tech.


As reported by many advocacy groups in the past few years, diversity remains a big debt in the tech industry. Only an average of 8.4% of employees in ten of the leading tech companies are Latinx(1). The gap is even bigger in open source software, where only 2.6% of committers to Apache projects are Latinx(2). Diversity in tech is not just the right thing to do, it is also good business: bringing more diverse participation in software development will result in more inclusive and successful products, that serve a more comprehensive set of use cases and needs in any given population.


While representation numbers in the creation of software are still looking grim, the use of OSS is growing fast: It is estimated that Cloud and big-data OSS technologies will grow five times by 2025 in Latin America. The main barrier for contributing? Language. 

The First Summit for Open Source Contributors set out to close this fundamental gap between tech users and its makers. To tackle this problem, we created, in partnership with other companies, 135 hours of content in Spanish for 481 participants, which produced over 200 new contributors across 19 open source projects. When asked why contributions from the region are so low, 41% of participants said it was due to lack of awareness, and 34% said they thought their contributions were not valuable. After the event, 47% of participants reported that the workshops and presentations provided them with information or guidance on how to contribute to specific projects, and 39% said the event helped them to lose fear and contribute. Almost 100% of participants stated that they plan to continue contributing to Open Source in the near future… and if they do, they would raise representation of Latinx in Open Source to 10%.
Organizing Team
This event left us with a lot of hope for the future of diversity and inclusion in open source. Going forward, we hope to continue supporting this summit in Latin America, and look for ways of reproducing this model in other regions of the world, as well as designing proactive outreach campaigns in other formats.

View more pictures of the event here.
View some of the recorded presentations here.


By: María Cruz for Google Open Source

(1) Aggregate data from Tech Crunch: https://techcrunch.com/2019/06/17/the-future-of-diversity-and-inclusion-in-tech/
(2) Data from the last Apache Software Foundation Committer Survey, applied in 2016, 765 respondents (13% of committers)

Why Diversity is Important in Open Source: Google’s Sponsorship of OSSEU

The Open Source Summit + Embedded Linux Conference is taking place in Lyon, France, which the Google Open Source Programs Office is sponsoring. The Linux Foundation supports shared technology through open source, while the conference provides a space for developers and technologists in open source to meet, network, and share knowledge with one another in order to advance the community. Why is this of utmost importance to Google OSS? Google has been rooted in the open source community for many years, supporting programs, projects, and organizations to help advance open source software and technology—we understand the necessity of sustaining open source and the developer community in order to advance technology as a whole.

Sponsoring OSSEU is more than just providing funds, but really pushing the diversity initiative in open source. We need diversity across all levels in open source whether it’s contributors, maintainers, doc writers, or anyone supporting the project. As said recently by the Open Source Initiative, “Many perspectives makes better software.” Having previously funded diversity initiatives such as scholarships or lunches at OSS conferences, Google continues to support this cause by sponsoring the diversity lunch at OSSEU.
In particular, sessions and events that Google will be hosting while at OSSEU include a keynote on Documentation by Megan Byrd-Sanicki and the Women in Open Source Lunch, both on Tuesday, October 29, 2019. The keynote on Docs highlights the importance of doc stars and why their contributions are essential to the growth of the open source community. Our support of the women in open source lunch is especially important as we look to increase the diversity of the open source community by supporting women and non-binary persons to get more involved and have the opportunity to connect with each other at an event of this scale.

If you’re attending OSSEU, stop by the keynote, and we hope to see you at the lunch as well. If you aren’t attending this year, and are interested in getting more involved in the open source community, the summits hosted by the Linux Foundation are one of the best ways to learn more about OSS and meet passionate people involved in different OSS projects and organizations.

By Radha Jhatakia, Google OSPO