Google Summer of Code turns 14

Google Open Source is proud to announce the 14th year of Google Summer of Code (GSoC)! Yes, GSoC is officially well into its teenage years - hopefully without that painful awkward stage - and we are excited to introduce more new student developers to the world of open source software development.

Over the last 13 years GSoC has provided over 13,000 university students from around the world with an opportunity to hone their skills by contributing to open source projects during their summer break. Participants gain invaluable experience working directly with mentors on open source projects, and earn a stipend upon successful completion of their project.

We’re excited to keep the tradition going! Applications for interested open source organizations open on January 4, 2018 and student applications open in March*.

Are you an open source project interesting in learning more? Visit the program site to learn about what it means to be a mentor organization and how to submit a good application. We welcome all types of organizations - both large and small - and each year about 20% of the organizations we accept are completely new to GSoC.

Students, it’s never too early to start thinking about your proposal. You can check out the organizations that participated in Google Summer of Code 2017 as well as the projects students worked on. We also encourage you to explore other resources like the student and mentor guides and frequently asked questions.

You can always learn more on the program website. Please stay tuned for more details!

By Mary Radomile, Google Open Source

* Exact dates will be announced later this year.

Authenticating to Hashicorp Vault using GCE Signed Metadata

Applications often require access to small pieces of sensitive data at build or run time, referred to as secrets. Secrets are generally more sensitive than other environment variables or parts of your repository as they may grant access to additional data, such as user information.

HashiCorp Vault is a popular open source tool for secret management, which allows a developer to store, manage and control access to tokens, passwords, certificates, API keys and other secrets. Vault has authentication backends, which allow developers to use many kinds of identities to access Vault, including tokens, or usernames and passwords.

Today, we’re announcing a new Google Compute Engine signed metadata authentication backend for Vault. This allows a developer to use an existing running instance to authenticate directly to Vault, using a JWT of this instance’s signed metadata as its identity. Learn more about the latest release of Vault.

The following example shows how a user can enable and configure the GCP auth backend and then authenticate an instance with Vault. See the docs to learn more.

In the following example, an admin mounts the backend at auth/gcp and adds:

• Credentials that the backend can use to verify the instance (requiring some read-only permissions)
• A Vault-specific role (roles determine what Vault secrets the authenticating GCE VM instance can access, and can restrict login to a set of instances by zone or region, instance group, or GCP labels)

# Mount the backend at ‘auth/gcp’.
$ vault auth-enable ‘gcp’
...

# Add configuration. This can include credentials Vault will 
# use to make calls to GCP APIs to verify authenticating instances. 
$ vault write auth/gcp/config credentials=@path/to/creds.json
...


# Add configuration. This can include credentials Vault will 
# use to make calls to GCP APIs to verify authenticating instances. 
$ vault write auth/gcp/role/my-gce-role \
type='gce' \
policies=’dev,prod’ \
project_id=”project-123456” \
zone="us-central1-c"
instance_group=”my-instance-group” \
labels=”foo:bar,prod:true,...” \
...

Then, a Compute Engine instance can authenticate to the Vault server using the following script:

#! /bin/bash

# [START PARAMS]
# Subtitute real vault address or env variable.
VAULT_ADDR="https://vault.rocks"

# Substitute another service account for the VM instance or use the
# built-in default.
SERVICE_ACCOUNT="default"

# The instance will attempt login under this role.
ROLE="my-gce-role"
# [END PARAMS]


# Generate a metadata identity token JWT with the expected audience.
# The GCP backend expect a JWT 'aud' claim ending in “vault/$ROLE”.
AUD="$VAULT_ADDR/vault/$ROLE"
TOKEN="$(curl -H "Metadata-Flavor: Google" \
http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=$AUD&format=full)"


# Attempt login against VAULT. 
# Using API calls:

cat > payload.json <<-END 
{ 
  "role": "$ROLE", 
  "jwt": "$TOKEN" 
}
END

$ RESP="$(curl \
    --request POST \
    --data @payload.json \
    $VAULT_ADDR/v1/auth/gcp/login)"

# OR

# Use CL vault tool if downloaded
vault write auth/gcp/login role=”$ROLE" jwt="$TOKEN" > response

# Get auth token from JSON
# response (response) and get
# your secrets from Vault!
# ...

A few weeks ago, we also announced a Google Cloud Platform IAM authentication backend for HashiCorp Vault, allowing authentication using an existing IAM service account identity. For further guidance on using HashiCorp Vault with Google Cloud, take a look at today’s Google Cloud blog post.

By Emily Ye, Software Engineer

Announcing Google Code-in 2017: The Latest and Greatest for Year Eight

We are excited to announce the 8th consecutive year of the Google Code-in (GCI) contest! Students ages 13 through 17 from around the world can learn about open source development working on real open source projects, with mentorship from active developers. GCI begins on Tuesday, November 28, 2017 and runs for seven weeks through to Wednesday, January 17, 2018.

Google Code-in is unique because not only do the students choose what they want to work on from the 2,000+ tasks created by open source organizations, but they have mentors available to help answer their questions as they work on each of their tasks.

Starting to work on open source software can be a daunting task in and of itself. How do I get started? Does the organization want my help? Am I too inexperienced? These are all questions that developers (of all ages) might consider before contributing to an open source organization.

The beauty of GCI is that participating open source organizations realize teens are often first time contributors, and the volunteer mentors are equipped with the patience and the experience to help these young minds become part of the open source community.

Open source communities thrive when there is a steady flow of new contributors who bring new perspectives, ideas, and enthusiasm. Over the last 7 years, GCI open source organizations have helped over 4,500 students from 99 countries become contributors. Many of these students are still contributing to open source years later. Dozens have gone on to become Google Summer of Code (GSoC) students and even mentors for other students.

The tasks open source organizations create vary in skill set and level, including beginner tasks any student can take on, such as “setup your development environment.” With tasks in five different categories, there’s something to fit almost any student’s skills:

• Code: writing or refactoring 
• Documentation/Training: creating/editing documents and helping others learn more
• Outreach/Research: community management, marketing, or studying problems and recommending solutions
• Quality Assurance: testing and ensuring code is of high quality
• User Interface: user experience research, user interface design, or graphic design

Open source organizations can apply to participate in Google Code-in starting on Monday, October 9, 2017. Google Code-in starts for students November 28th!

Visit the contest site g.co/gci to learn more about the contest and find flyers, slide decks, timelines and more.

By Stephanie Taylor, Google Open Source