Category Archives: Open Source Blog

News about Google’s open source projects and programs

Know, Prevent, Fix: A framework for shifting the discussion around vulnerabilities in open source

Executive Summary:
The security of open source software has rightfully garnered the industry’s attention, but solutions require consensus about the challenges and cooperation in the execution. The problem is complex and there are many facets to cover: supply chain, dependency management, identity, and build pipelines. Solutions come faster when the problem is well-framed; we propose a framework (“Know, Prevent, Fix”) for how the industry can think about vulnerabilities in open source and concrete areas to address first, including:
  • Consensus on metadata and identity standards: We need consensus on fundamentals to tackle these complex problems as an industry. Agreements on metadata details and identities will enable automation, reduce the effort required to update software, and minimize the impact of vulnerabilities.
  • Increased transparency and review for critical software: For software that is critical to security, we need to agree on development processes that ensure sufficient review, avoid unilateral changes, and transparently lead to well-defined, verifiable official versions.
The following framework and goals are proposed with the intention of sparking industry-wide discussion and progress on the security of open source software.


Due to recent events, the software world gained a deeper understanding about the real risk of supply-chain attacks. Open source software should be less risky on the security front, as all of the code and dependencies are in the open and available for inspection and verification. And while that is generally true, it assumes people are actually looking. With so many dependencies, it is impractical to monitor them all, and many open source packages are not well maintained.

It is common for a program to depend, directly or indirectly, on thousands of packages and libraries. For example, Kubernetes now depends on about 1,000 packages. Open source likely makes more use of dependencies than closed source, and from a wider range of suppliers; the number of distinct entities that need to be trusted can be very high. This makes it extremely difficult to understand how open source is used in products and what vulnerabilities might be relevant. There is also no assurance that what is built matches the source code.

Taking a step back, although supply-chain attacks are a risk, the vast majority of vulnerabilities are mundane and unintentional—honest errors made by well-intentioned developers. Furthermore, bad actors are more likely to exploit known vulnerabilities than to find their own: it’s just easier. As such, we must focus on making fundamental changes to address the majority of vulnerabilities, as doing so will move the entire industry far along in addressing the complex cases as well, including supply-chain attacks.

Few organizations can verify all of the packages they use, let alone all of the updates to those packages. In the current landscape, tracking these packages takes a non-trivial amount of infrastructure, and significant manual effort. At Google, we have those resources and go to extraordinary lengths to manage the open source packages we use—including keeping a private repo of all open source packages we use internally—and it is still challenging to track all of the updates. The sheer flow of updates is daunting. A core part of any solution will be more automation, and this will be a key theme for our open source security work in 2021 and beyond.

Because this is a complex problem that needs industry cooperation, our purpose here is to focus the conversation around concrete goals. Google co-founded the OpenSSF to be a focal point for this collaboration, but to make progress, we need participation across the industry, and agreement on what the problems are and how we might address them. To get the discussion started, we present one way to frame this problem, and a set of concrete goals that we hope will accelerate industry-wide solutions.

We suggest framing the challenge as three largely independent problem areas, each with concrete objectives:
  1. Know about the vulnerabilities in your software
  2. Prevent the addition of new vulnerabilities, and
  3. Fix or remove vulnerabilities.
A related but separate problem, which is critical to securing the supply chain, is improving the security of the development process. We’ve outlined the challenges of this problem and proposed goals in the fourth section, Prevention for Critical Software.

Know your Vulnerabilities

Knowing your vulnerabilities is harder than expected for many reasons. Although there are mechanisms for reporting vulnerabilities, it is hard to know if they actually affect the specific versions of software you are using.

Goal: Precise Vulnerability Data
First, it is crucial to capture precise vulnerability metadata from all available data sources. For example, knowing which version introduced a vulnerability helps determine if one's software is affected, and knowing when it was fixed results in accurate and timely patching (and a reduced window for potential exploitation). Ideally, this triaging workflow should be automated.

Second, most vulnerabilities are in your dependencies, rather than the code you write or control directly. Thus, even when your code is not changing, there can be a constant churn in your vulnerabilities: some get fixed and others get added.1

Goal: Standard Schema for Vulnerability Databases
Infrastructure and industry standards are needed to track and maintain open source vulnerabilities, understand their consequences, and manage their mitigations. A standard vulnerability schema would allow common tools to work across multiple vulnerability databases and simplify the task of tracking, especially when vulnerabilities touch multiple languages or subsystems.

Goal: Accurate Tracking of Dependencies
Better tooling is needed to understand quickly what software is affected by a newly discovered vulnerability, a problem made harder by the scale and dynamic nature of large dependency trees. Current practices also often make it difficult to predict exactly what versions are used without actually doing an installation, as the software for version resolution is only available through the installer.

Prevent New Vulnerabilities

It would be ideal to prevent vulnerabilities from ever being created, and although testing and analysis tools can help, prevention will always be a hard problem. Here we focus on two specific aspects:
  • Understanding risks when deciding on a new dependency
  • Improving development processes for security-critical software
Goal: Understand the Risks for New Dependencies
The first category is essentially knowing about vulnerabilities at the time you decide to use a package. Taking on a new dependency has inherent risk and it needs to be an informed decision. Once you have a dependency, it generally becomes harder to remove over time. Knowing about vulnerabilities is a great start, but there is more that we can do. Continue reading

Google Summer of Code 2021 is open for mentor organization applications!

GSoC logo
With the new year comes the start of our 17th edition of Google Summer of Code (GSoC)! Right now open source projects and organizations can apply to participate as mentoring organizations for the students in the 2021 program. GSoC is a global program that draws student developers (18 years old and over) from around the world to contribute to open source projects. This year, from June 7th to August 16th, each student will spend 10 weeks working on a coding project with the support of volunteer mentors from participating open source organizations.

Does your open source project want to learn more about becoming a mentoring organization? Visit the program site and read the mentor guide to learn about what it means to be a mentor organization, how to prepare your community (hint: have plenty of enthusiastic mentors!), creating appropriate project ideas (that will be ~175 hour projects for the student), and tips for preparing your application.

We welcome all types of organizations and are very eager to involve first-time organizations with a 2021 goal of accepting 40 new orgs. We encourage veteran organizations to refer other organizations they think would be a good fit to participate in GSoC as well.

Last year, 1,106 students completed the program under the guidance of over 2,000 mentors from 198 open source organizations. Many types of open source organizations are involved in GSoC, from small and medium sized open source organizations to larger, umbrella organizations with many sub-projects under them (Python Software Foundation, Apache Software Foundation, etc.). Some organizations are relatively young (less than 2 years old), while other organizations have been around for 20+ years.

You can apply to be a mentoring organization for GSoC starting today on the program site. The deadline to apply is February 19th at 19:00 UTC. We will publicly announce the organizations chosen for GSoC 2021 on March 9th.

Please visit the program site for more information on how to apply and review the detailed timeline of important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects want to be a part of the GSoC program.

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

Google Summer of Code 2021 is open for mentor organization applications!

GSoC logo
With the new year comes the start of our 17th edition of Google Summer of Code (GSoC)! Right now open source projects and organizations can apply to participate as mentoring organizations for the students in the 2021 program. GSoC is a global program that draws student developers (18 years old and over) from around the world to contribute to open source projects. This year, from June 7th to August 16th, each student will spend 10 weeks working on a coding project with the support of volunteer mentors from participating open source organizations.

Does your open source project want to learn more about becoming a mentoring organization? Visit the program site and read the mentor guide to learn about what it means to be a mentor organization, how to prepare your community (hint: have plenty of enthusiastic mentors!), creating appropriate project ideas (that will be ~175 hour projects for the student), and tips for preparing your application.

We welcome all types of organizations and are very eager to involve first-time organizations with a 2021 goal of accepting 40 new orgs. We encourage veteran organizations to refer other organizations they think would be a good fit to participate in GSoC as well.

Last year, 1,106 students completed the program under the guidance of over 2,000 mentors from 198 open source organizations. Many types of open source organizations are involved in GSoC, from small and medium sized open source organizations to larger, umbrella organizations with many sub-projects under them (Python Software Foundation, Apache Software Foundation, etc.). Some organizations are relatively young (less than 2 years old), while other organizations have been around for 20+ years.

You can apply to be a mentoring organization for GSoC starting today on the program site. The deadline to apply is February 19th at 19:00 UTC. We will publicly announce the organizations chosen for GSoC 2021 on March 9th.

Please visit the program site for more information on how to apply and review the detailed timeline of important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects want to be a part of the GSoC program.

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

Google Summer of Code 2021 is open for mentor organization applications!

GSoC logo
With the new year comes the start of our 17th edition of Google Summer of Code (GSoC)! Right now open source projects and organizations can apply to participate as mentoring organizations for the students in the 2021 program. GSoC is a global program that draws student developers (18 years old and over) from around the world to contribute to open source projects. This year, from June 7th to August 16th, each student will spend 10 weeks working on a coding project with the support of volunteer mentors from participating open source organizations.

Does your open source project want to learn more about becoming a mentoring organization? Visit the program site and read the mentor guide to learn about what it means to be a mentor organization, how to prepare your community (hint: have plenty of enthusiastic mentors!), creating appropriate project ideas (that will be ~175 hour projects for the student), and tips for preparing your application.

We welcome all types of organizations and are very eager to involve first-time organizations with a 2021 goal of accepting 40 new orgs. We encourage veteran organizations to refer other organizations they think would be a good fit to participate in GSoC as well.

Last year, 1,106 students completed the program under the guidance of over 2,000 mentors from 198 open source organizations. Many types of open source organizations are involved in GSoC, from small and medium sized open source organizations to larger, umbrella organizations with many sub-projects under them (Python Software Foundation, Apache Software Foundation, etc.). Some organizations are relatively young (less than 2 years old), while other organizations have been around for 20+ years.

You can apply to be a mentoring organization for GSoC starting today on the program site. The deadline to apply is February 19th at 19:00 UTC. We will publicly announce the organizations chosen for GSoC 2021 on March 9th.

Please visit the program site for more information on how to apply and review the detailed timeline of important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects want to be a part of the GSoC program.

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

Google Summer of Code 2021 is open for mentor organization applications!

GSoC logo
With the new year comes the start of our 17th edition of Google Summer of Code (GSoC)! Right now open source projects and organizations can apply to participate as mentoring organizations for the students in the 2021 program. GSoC is a global program that draws student developers (18 years old and over) from around the world to contribute to open source projects. This year, from June 7th to August 16th, each student will spend 10 weeks working on a coding project with the support of volunteer mentors from participating open source organizations.

Does your open source project want to learn more about becoming a mentoring organization? Visit the program site and read the mentor guide to learn about what it means to be a mentor organization, how to prepare your community (hint: have plenty of enthusiastic mentors!), creating appropriate project ideas (that will be ~175 hour projects for the student), and tips for preparing your application.

We welcome all types of organizations and are very eager to involve first-time organizations with a 2021 goal of accepting 40 new orgs. We encourage veteran organizations to refer other organizations they think would be a good fit to participate in GSoC as well.

Last year, 1,106 students completed the program under the guidance of over 2,000 mentors from 198 open source organizations. Many types of open source organizations are involved in GSoC, from small and medium sized open source organizations to larger, umbrella organizations with many sub-projects under them (Python Software Foundation, Apache Software Foundation, etc.). Some organizations are relatively young (less than 2 years old), while other organizations have been around for 20+ years.

You can apply to be a mentoring organization for GSoC starting today on the program site. The deadline to apply is February 19th at 19:00 UTC. We will publicly announce the organizations chosen for GSoC 2021 on March 9th.

Please visit the program site for more information on how to apply and review the detailed timeline of important deadlines. We also encourage you to check out the Mentor Guide and our short video on why open source projects want to be a part of the GSoC program.

Good luck to all open source mentoring organization applicants!

By Stephanie Taylor, Google Open Source

The Future of Tilt Brush

Tilt Brush by Google

Open Sourcing Tilt Brush

Tilt Brush, Google's virtual reality painting application, has collaborated with amazing creators over the years, many of whom were part of our Artist in Residence Program. We have tremendous pride for all those collaborations, and the best part has been watching our community learn from each other and develop their abilities over the years.

As we continue to build helpful and immersive AR experiences, we want to continue supporting the artists using Tilt Brush by putting it in your hands. This means open sourcing Tilt Brush, allowing everyone to learn how we built the project, and encouraging them to take it in directions that are near and dear to them.

Tilt Brush launched on the SteamVR platform for the HTC Vive VR headset in April 2016. It went on to help users create their artwork on every major VR platform, including the Oculus Rift, Windows Mixed Reality, Valve Index, PlayStation VR, and Oculus Quest VR headsets. Tilt Brush won dozens of awards, including the Unity Awards 2015: Best VR Experience, the Cannes Lions 2017 Gold Lion in Innovation, and the Oculus Quest award for Best of 2019: VR Creativity Tool of the Year, and was often featured on The Tonight Show Starring Jimmy Fallon. As we look back on Tilt Brush, we’re proud of what this creative application has achieved, and excited for where the community will take it.
Tilt Brush by Google

What’s Included

The open source archive of the Tilt Brush code can be found at: https://github.com/googlevr/tilt-brush

Please note that it is not an actively developed product, and no pull requests will be accepted. You can use, distribute, and modify the Tilt Brush code in accordance with the Apache 2.0 License under which it is released.

In order to be able to release the Tilt Brush code as open source, there were a few things we had to change or remove due to licensing restrictions. In almost all cases, we documented the process for adding those features back in our comprehensive build guide. ‘Out of the box’, the code in the archive will compile a working version of Tilt Brush, requiring you only to add the SteamVR Unity SDK.

The currently published version of Tilt Brush will always remain available in digital stores for users with supported VR headsets. If you're interested in creating your own Tilt Brush experience, please review the build guide and visit our github repo to access the source code.

Cheers, and happy painting from the Tilt Brush team!

By Tim Aidley, Software Engineer, and Jon Corralejo, Program Manager – Tilt Brush

Assess the security of Google Kubernetes Engine (GKE) with InSpec for GCP

We are excited to announce the GKE CIS 1.1.0 Benchmark InSpec profile under an open source software license is now available on GitHub, which allows you to assess Google Kubernetes Engine (GKE) clusters against security controls recommended by CIS. You can validate the security posture of your GKE clusters using Chef InSpec™ by assessing their compliance against the Center for Internet Security (CIS) 1.1.0 benchmark for GKE.

Validating security compliance of GKE

GKE is a popular platform to run containerized applications. Many organizations have selected GKE for its scalability, self-healing, observability and integrations with other services on Google Cloud. Developer agility is one of the most compelling arguments for moving to a microservices architecture on Kubernetes, introducing configuration changes at a faster pace and demanding security checks as part of the development lifecycle.

Validating the security settings of your GKE cluster is a complex challenge and requires an analysis of multiple layers within your Cloud infrastructure:

GKE is a managed service on GCP, with controls to tweak the cluster’s behaviour which have an impact on its security posture. These Cloud resource configurations can be configured and audited via Infrastructure-as-Code (IaC) frameworks such as Terraform, the gcloud command line or the Google Cloud Console.

Application workloads are deployed on GKE by interacting via the Kubernetes (K8S) API. Kubernetes resources such as pods, deployments and services are often deployed from yaml templates using the command line tool kubectl.

Kubernetes uses configuration files (such as the kube-proxy and kubelet file) typically in yaml format which are stored on the nodes’ file system.

InSpec for auditing GKE

InSpec is a popular DevSecOps framework that checks the configuration state of resources in virtual machines and containers, on Cloud providers such as Google Cloud, AWS, and Microsoft Azure. The InSpec GCP resource pack 1.8 (InSpec-GCP) provides a consistent way to audit GCP resources and can be used to validate the attributes of a GKE cluster against a desired state declared in code. We previously released a blog post on how to validate your Google Cloud resources with InSpec-GCP against compliance profiles such as the CIS 1.1.0 benchmark for GCP.

While you can use the InSpec-GCP resource pack to define the InSpec controls to validate resources against the Google Cloud API, it does not directly allow you to validate configurations of other relevant layers such as Kubernetes resources and config files on the nodes. Luckily, the challenge to audit Kubernetes resources with InSpec has already been solved by the inspec-k8s resource pack. Further, files on nodes can be audited using remote access via SSH. All together, we can validate the security posture of GKE holistically using the inspec-gcp and inspec-k8s resource packs as well as controls using the InSpec file resource executed in an ssh session.

Running the CIS for GKE compliance profile with InSpec

With the GKE CIS 1.1.0 Benchmark InSpec Profile we have implemented the security controls to validate a GKE cluster against the recommended settings on GCP resource level, Kubernetes API level and file system level. The repository is split into three profiles (inspec-gke-cis-gcp, inspec-gke-cis-k8s and inspec-gke-cis-ssh), since each profile requires a different “target”, or -t parameter when run using the InSpec command line. For ease of use, a wrapper script run_profiles.sh has been provided in the root directory of the repository with the purpose of running all three profiles and storing the reports in the dedicated folder reports.
The script requires the cluster name (-c), ssh username (-u), private key file for ssh authentication (-k), cluster region or zone (-r or -z) and InSpec input file as required by the inspec.yml files in each profile (-i). As an example, the following line will run all three profiles to validate the compliance of cluster inspec-cluster in zone us-central1-a:

./run_profiles.sh -c inspec-cluster \
                           -u konrad \
                           -k /home/konrad/.ssh/google_compute_engine \
                           -z us-central1-a \
                           -i inputs.yml
Running InSpec profile inspec-gke-cis-gcp ...

Profile: InSpec GKE CIS 1.1 Benchmark (inspec-gke-cis-gcp)
Version: 0.1.0
Target: gcp://<service account used for InSpec>

<lots of InSpec output omitted>

Profile Summary: 16 successful controls, 10 control failures2 controls skipped
Test Summary: 18 successful, 11 failures, 2 skipped
Stored report in reports/inspec-gke-cis-gcp_report.
Running InSpec profile inspec-gke-cis-k8s …

Profile: InSpec GKE CIS 1.1 Benchmark (inspec-gke-cis-k8s)
Version: 0.1.0
Target: kubernetes://<IP address of K8S endpoint>:443

<lots of InSpec output omitted>

Profile Summary: 9 successful controls, 1 control failure, 0 controls skipped
Test Summary: 9 successful, 1 failure, 0 skipped
Stored report in reports/inspec-gke-cis-gcp_report.
Running InSpec profile inspec-gke-cis-ssh on node <cluster node 1> ...

Profile: InSpec GKE CIS 1.1 Benchmark (inspec-gke-cis-ssh)
Version: 0.1.0
Target: ssh://<username>@<cluster node 1>:22

<lots of InSpec output omitted>

Profile Summary: 10 successful controls, 5 control failures, 1 control skipped
Test Summary: 12 successful, 6 failures, 1 skipped
Stored report in reports/inspec-gke-cis-ssh_<cluster node 1>_report.


Analyze your scan reports

Once the wrapper script has completed successfully you should analyze the JSON or HTML reports to validate the compliance of your GKE cluster. One way to perform the analysis is to upload the collection of JSON reports of a single run from the reports folder to the open source InSpec visualization tool Heimdall Lite (GitHub) by the Mitre Corporation. An example of a compliance dashboard is shown below:
Scan Reports dashboard


Try it yourself and run the GKE CIS 1.1.0 Benchmark InSpec profile in your Google Cloud environment! Clone the repository and follow the CLI example in the Readme file to run the InSpec profiles against your GKE clusters. We also encourage you to report any issues on GitHub that you may find, suggest additional features and to contribute to the project using pull requests. Also, you can read our previous blog post on using InSpec-GCP for compliance validations of your GCP environment.

By Bakh Inamov, Security Specialist Engineer and Konrad Schieban, Infrastructure Cloud Consultant

The API Registry API

We’ve found that many organizations are challenged by the increasing number of APIs that they make and use. APIs become harder to track, which can lead to duplication rather than reuse. Also, as APIs expand to cover an ever-broadening set of topics, they can proliferate different design styles, at times creating frustrating inefficiencies.

To address this, we’ve designed the Registry API, an experimental approach to organizing information about APIs. The Registry API allows teams to upload and share machine-readable descriptions of APIs that are in use and in development. These descriptions include API specifications in standard formats like OpenAPI, the Google API Discovery Service Format, and the Protocol Buffers Language.

An organized collection of API descriptions can be the foundation for a wide range of tools and services that make APIs better and easier to use.
  • Linters verify that APIs follow standard patterns
  • Documentation generators provide documentation in consistent, easy-to-read, accessible formats
  • Code generators produce API clients and server scaffolding
  • Searchable online catalogs make everything easier to find
But perhaps most importantly, bringing everything about APIs together into one place can accelerate the consistency of an API portfolio. With organization-wide visibility, many find they need less explicit governance even as their APIs become more standardized and easy to use.

The Registry API is a gRPC service that is formally described by Protocol Buffers and that closely follows the Google API Design Guidelines at aip.dev. The Registry API description is annotated to support gRPC HTTP/JSON transcoding, which allows it to be automatically published as a JSON REST API using a proxy. Proxies also enable gRPC web, which allows gRPC calls to be directly made from browser-based applications, and the project includes an experimental GraphQL interface.

We’ve released a reference implementation that can be run locally or deployed in a container with Google Cloud Run or other container-based services. It stores data using the Google Cloud Datastore API or a configurable relational interface layer that currently supports PostgreSQL and SQLite.

Following AIP-181, we’ve set the Registry API’s stability level as "alpha," but our aim is to make it a stable base for API lifecycle applications. We’ve open-sourced our implementation to share progress and gather feedback. Please tell us about your experience if you use it.

By Tim Burks, Tech Lead – Apigee API Lifecycle and Governance

Season of Docs announces results of 2020 program

Season of Docs has announced the 2020 program results for standard-length projects. You can view a list of successfully completed technical writing projects on the website along with their final project reports.

Seasons of docs graphic
During the program, technical writers spend a few months working closely with an open source community. They bring their technical writing expertise to improve the project's documentation while the open source projects provided mentors to introduce the technical writers to open source tools, workflows, and the project's technology.

For standard-length technical writing projects in Season of Docs, the doc development phase is September 14, 2020 – November 30, 2020. However, some technical writers may apply for a long-running project. The technical writer makes this decision under consultation with the open source organization, based on the expectations for their project. For a long-running project, the doc development phase is September 14, 2020 – March 1, 2021.

64 technical writers successfully completed their standard-length technical writing projects. There are 18 long-running projects in progress that are expected to finish in March.
  • 80% of the mentors had a positive experience and want to mentor again in future Season of Docs cycles
  • 96% of the technical writers had a positive experience
  • 96% plan to continue contributing to open source projects
  • 94% of the technical writers said that Season of Docs helped improved their knowledge of code and/or open source
Take a look at the list of successful projects to see the wide range of subjects covered!

What is next?

The long-running projects are still in progress and finish in March 2021. Technical writers participating in these long-running projects submit their project reports before March 8th, and the writer and mentor evaluations are due by March 12th. Successfully completed long-running technical writing projects will be published on the results page on March 15, 2021.

If you were excited about participating, please do write social media posts. See the promotion and press page for images and other promotional materials you can include, and be sure to use the tag #SeasonOfDocs when promoting your project on social media. To include the tech writing and open source communities, add #WriteTheDocs, #techcomm, #TechnicalWriting, and #OpenSource to your posts.

Stay tuned for information about Season of Docs 2021—watch for posts in this blog and sign up for the announcements email list.

By Kassandra Dhillon and Erin McKean, Google Open Source Programs Office

Using MicroK8s with Anthos Config Management in the world of IoT

When dealing with large scale Kubernetes deployments, managing configuration and policy is often very complicated. We discussed why Kubernetes’ declarative approach to configuration as data has become the most popular choice for most users a few weeks ago. Today, we will discuss bringing this approach to your MicroK8 deployments using Anthos Config Management.
Image of Anthos Config Management + Cloud Source Repositories + MicroK8s
Anthos Config Management helps you easily create declarative security and operational policies and implement them at scale for your Kubernetes deployments across hybrid and multi-cloud environments. At a high level, you represent the desired state of your deployment as code committed to a central Git repository. Anthos Config Management will ensure the desired state is achieved and also maintained across all your registered clusters.

You can use Anthos Config Management for both your Kubernetes Engine (GKE) clusters as well as on Anthos attached clusters. Anthos attached clusters is a deployment option that extends Anthos’ reach into Kubernetes clusters running in other clouds as well as edge devices and the world of IoT, the Internet of Things. In this blog you will learn by experimenting with attached clusters with MicroK8s, a conformant Kubernetes platform popular in IoT and edge environments.

Consider an organization with a large number of distributed manufacturing facilities or laboratories that use MicroK8s to provide services to IoT devices. In such a deployment, Anthos can help you manage remote clusters directly from the Anthos Console rather than investing engineering resources to build out a multitude of custom tools.

Consider the diagram below.

Diagram of Anthos Config Management with MicroK8s on the Factory Floor with IoT
This diagram shows a set of “N” factory locations each with a MicroK8s cluster supporting IoT devices such as lights, sensors, or even machines. You register each of the MicroK8s clusters in an Anthos environ: a logical collection of Kubernetes clusters. When you want to deploy the application code to the MicroK8s clusters, you commit the code to the repository and Anthos Config Management takes care of the deployment across all locations. In this blog we will show you how you can quickly try this out using a MicroK8s test deployment.

We will use the following Google Cloud services:
  • Compute Engine provides an Ubuntu instance for a single-node MicroK8s cluster. Ubuntu will use cloud-init to install MicroK8s and generate shell scripts and other files to save time.
  • Cloud Source Repositories will provide the Git-based repository to which we will commit our workload.
  • Anthos Config Management will perform the deployment from the repository to the MicroK8s cluster.

Let’s start with a picture

Here’s a diagram of how these components fit together.

Diagram of how Anthos Config Management works together with MicroK8s
  • A workstation instance is created from which Terraform is used to deploy four components: (1) an IAM service account, (2) a Google Compute Engine Instance with MicroK8s using permissions provided by the service account, (3) a Kubernetes configuration repo provided by Cloud Source Repositories, and (4) a public/private key pair.
  • The GCE instance will use the service account key to register the MicroK8s cluster with an Anthos environ.
  • The public key from the public/ private key pair will be registered to the repository while the private key will be registered with the MicroK8s cluster.
  • Anthos Config Management will be configured to point to the repository and branch to poll for updates.
  • When a Kubernetes YAML document is pushed to the appropriate branch of the repository, Anthos Config Management will use the private key to connect to the repository, detect that a commit has been made against the branch, fetch the files and apply the document to the MicroK8s cluster.
Anthos Config Management enables you to deploy code from a Git repository to Kubernetes clusters that have been registered with Anthos. Google Cloud officially supports GKE, AKS, and EKS clusters, but you can use other conformant clusters such as MicroK8s in accordance with your needs. The repository below shows you how to register a single MicroK8s cluster to receive deployments. You can also scale this to larger numbers of clusters all of which can receive updates from commitments to the repository. If your organization has large numbers of IoT devices supported by Kubernetes clusters you can update all of them from the Anthos console to provide for consistent deployments across the organization regardless of the locations of the clusters, including the IoT edge. If you would like to learn more, you can build this project yourself. Please check out this Git repository and learn firsthand about how Anthos can help you manage Kubernetes deployments in the world of IoT.

By Jeff Levine, Customer Engineer – Google Cloud