By Maya Kaczorowski, Security and Privacy Product Manager; and Emily Ye, Software Engineer

Open source technology encourages collaboration and innovation to address real world problems, including projects supported by Google Cloud. As part of our broad engagement with the open source community, we’ve been working with HashiCorp since 2013 to enable customers who use HashiCorp tools to make optimal use of Google Cloud Platform (GCP) services and features.

A longstanding, productive collaboration 

Google and HashiCorp have dedicated engineering teams focused on enhancing and expanding GCP support in HashiCorp products. We're focused on technical and shared go-to-market efforts around HashiCorp products in several critical areas of infrastructure.

• Cloud provisioning: The Google Cloud provider for HashiCorp Terraform allows management of a broad array of GCP resource types, with Bigtable and BigQuery being the most recent additions. Today, HashiCorp also announced support for GCP in the Terraform Module Registry to give users easy access to templates for setting up and running their GCP-based infrastructure. We plan to continue to broaden the number of GCP services that can be provisioned with Terraform, allowing Terraform users to adopt a familiar workflow across multiple cloud and on-premises environments. Using Terraform to move workloads to GCP simplifies the cloud adoption process for Google customers that use Terraform today in cross-cloud environments. 
• Cloud security and secret management: We're working to enhance the integration between HashiCorp Vault and GCP, including Vault authentication backends for IAM and signed VM metadata. This is in addition to work being done by HashiCorp for Kubernetes authentication. 

Using HashiCorp Vault with Google Cloud and Kubernetes 

Applications often require access to small pieces of sensitive data at build or run time, referred to as secrets. 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 many options for authentication, known as authentication backends. These allow developers to use many kinds of credentials to access Vault, including tokens, or usernames and passwords.

As of today, developers on Google Cloud now have two authentication backends which they can use to validate a service’s identity to their instance of Vault: 

• GCP IAM service accounts: a new Google Cloud Platform IAM authentication backend for Vault allows you to use an existing IAM identity to authenticate to Vault. 
• Google Compute Engine instance identity tokens: announced today, this uses an instance’s signed metadata token to authenticate to Vault. 

With these authentication backends, it’s easier for a particular service running on Google Cloud to get access to a secret it needs at build or run time stored in Vault.

Fleetsmith is a secure cloud-based solution for managing a company’s Mac computers, that fully integrates with G Suite. They’ve been testing out the new Compute Engine metadata backend, and are currently using Vault on GCP for PKI and secret management. Learn more about how Fleetsmith did this in their blogpost.

“Fleetsmith and Google have shared values when it comes to security, and we built our product on Google Cloud Platform in part due to Google's high bar for security. We're excited about this new integration because it strengthens the security model for us as Google Cloud customers using Vault.” 

— Jesse Endahl, CPO and CSO, Fleetsmith 

If you’re using Vault for managing secrets in Kubernetes specifically, today HashiCorp announced a new Kubernetes authentication backend. This uses Kubernetes pod service accounts to authenticate to Vault, providing an alternative to storing secrets in directly in `etcd`.

Running HashiCorp Vault on Google Cloud 

You may already be running your own instance of HashiCorp Vault. Users can run Vault in either Compute Engine or Google Container Engine, and then use one of our new authentication backends to authenticate to Vault.

WePay, an online payment service provider, uses HashiCorp Vault on GCP:

 "Managing usernames, passwords and certificates is a challenge in a microservice world, where we have to securely manage many secrets for hundreds of microservices. WePay chose to use HashiCorp Vault to store secrets because it provides us with rotation, tight control and out-of-the-box audit logging for our secrets and other sensitive data. WePay runs Vault server infrastructure on Google Compute Engine for secret storage, key management and service to service authentication, for use by our microservice architecture based on Google Container Engine."  

— Akshath Kumar, Site Reliability Engineer, WePay 

eBay also uses HashiCorp Vault on GCP:

“As a strong contributor and supporter of free open source software with vital projects such as regressr and datameta, eBay is a user of Hashicorp’s software products, including vaultproject.io on the Google Cloud Platform.”  

— Mitch Wyle, Director of Applied Science and Engineering, eBay 

Today, we’re publishing a solution on how to best set up and run HashiCorp Vault on Compute Engine. For best practices for running Vault on Compute Engine, read the solution brief “Using Vault on Compute Engine for Secret Management”.

Using HashiCorp Terraform to manage your resources on Google Cloud 

When you’re testing new code or software, you might want to spin up a test environment to simulate your application. HashiCorp Terraform is an infrastructure management and deployment tool that allows you to programmatically configure infrastructure across a variety of providers, including cloud providers like Google Cloud.

Using Terraform on Google Cloud, you can programmatically manage projects, IAM policies, Compute Engine resources, BigQuery datasets and more. To get started with Terraform for Google Cloud, check out the Terraform Google Cloud provider documentation, take a look at our tutorial for managing GCP projects with Terraform, which you can follow on our community page, or watch our Terraform for Google Cloud demo.

Google has released a number of Terraform modules that make working with Google Cloud even easier. These modules let you quickly compose your architectures as code and reuse architectural patterns for resources like load balancing, managed instance groups, NAT gateways and SQL databases. The modules can be found on the Terraform Module Registry.

Get involved 

We’re always excited about new contributors to open source projects we support. If you’d like to contribute, please get involved in projects like Kubernetes, istio, as well as Vault and Terraform. The community is what makes these projects successful. To learn more about open source projects we support, see Open Source at Google.

By Dan Ciruli, Product Manager

The shift from on-premises to cloud computing is rarely sudden and rarely complete. Workloads move over time; in some cases new workloads get built in the cloud and old workloads stay on-premises. In other cases, organizations lift and shift some services and continue to do new developments on their own infrastructure. And, of course, many companies have deployments in multiple clouds.

When you run services across a wide array of resources and locations, you need to secure communications between them. Networking may be able to solve some issues, but it can be difficult in many cases: if you're running containerized workloads on hardware that belongs to three different vendors, good luck setting up a VPN to protect that traffic.

Increasingly, our customers use Google Cloud Endpoints to authenticate and authorize calls to APIs rather than (or even in addition to) trying to secure them through networking. In fact, providing more security for calls across a hybrid environment was one of the original use cases for Cloud Endpoints adopters.

"When migrating our workloads to Google Cloud Platform, we needed to more securely communicate between multiple data centers. Traditional methods like firewalls and ad hoc authentication were unsustainable, quickly leading to a jumbled mess of ACLs. Cloud Endpoints, on the other hand, gives us a standardized authentication system." 

—  Laurie Clark-Michalek, Infrastructure Engineer, Qubit 

Cloud Endpoints uses the Extensible Service Proxy, based on NGINX, which can validate a variety of authentication schemes from JWT tokens to API keys. We deploy that open source proxy automatically if you use Cloud Endpoints on App Engine Flexible environment, but it is also available via the Google Container Registry for deployment anywhere: on Google Container Engine, on-premises, or even in another cloud.

Protecting APIs with JSON Web Tokens 

One of the most common and more secure ways to protect your APIs is to require a JSON Web Token (JWT). Typically, you use a service account to represent each of your services, and each service account has a private key that can be used to sign a JSON Web Token.

If your (calling) service runs on GCP, we manage the key for you automatically; simply invoke the IAM.signJwt method on your JSON web token and put the resulting signed JWT in the OAuth Authorization: Bearer header on your call.

If your service runs on-premises, install ESP as a sidecar that proxies all traffic to your service. Your API configuration tells ESP which service account will be placing the calls. ESP uses the public key for your service account to validate that it was signed properly, and validates several fields in the JWT as well.

If the service is on-premises and calling to the cloud, you still need to sign your JWT, but it’s your responsibility to manage the private key. In that case, download the private key from Cloud Console (following best practices to help securely store it) and sign your JWTs.

For more details, check out the sample code and documentation on service-to-service authentication (or this, if you're using gRPC).

Securing APIs with API keys 

Strictly speaking, API keys are not authentication tokens. They're longer-lived and more dangerous if stolen. However, they do provide a quick and easy way to protect an API by easily adding them to a call — either in a header or as a query parameter.

API keys also allow an API’s consumers to generate their own credentials. If you’ve ever called a Google API that doesn’t involve personal data, for example the Google Maps Javascript API, you’ve used an API key.

To restrict access to an API with an API key, follow these directions. After that, you’ll need to generate a key. You can generate the key in that same project (following these directions). Or you can share your project with another developer. Then, in the project that will call your API, that developer can create an API key and enable the API. Add the key to the API calls as a query parameter (just add ?key=${ENDPOINTS_KEY} to your request) or in the x-api-key header (see the documentation for details).

Wrapping up 

Securing APIs is good practice no matter where they run. At Google, we use authentication for inter-service communication, even if both run entirely on our production network. But if you live in a hybrid cloud world, authenticating each and every call is even more important.

To get started with Cloud Endpoints, take a look at our tutorials. It’s a great way to build scalable and more secure applications that can span a variety of cloud and on-premises environments.

By Sharon Maher, Managing Editor, Google Cloud Blogs and Social

From mobile phones to the internet, technology has revolutionized our lives — and we have programmers to thank for it. And, fortunately, now we can. Falling on the 256th day of the year, Programmer’s Day recognizes the works of programmers everywhere, from code hobbyists to technological innovators.

It should come as no surprise that Programmer’s Day has a special place in our hearts. To celebrate, this year we asked our engineers to tell us about the first program they wrote that they were proud of. We learned a lot. And, as it turns out, we discovered that many of our engineers have very patient parents. Read on.

Not surprisingly, many Googlers started out by writing their own games. Jen Tong wrote a text adventure game in the mid-’90s. “It was 20,000 lines of QBASIC spaghetti code. Recognizing that IF and GOTO were enough to write any program, I disregarded my father's advice to use loops and subroutines.” But there was an unexpected upside to her efforts. “Terrible as it was, it inspired several of my friends to sling their own code.”

Todd Kerpelman, a Firebase Developer Advocate, created his first in BASIC for the Apple IIe. “It had everything,” he says. “A blocky-looking dragon, a blocky-looking sword, and a booby-trapped room where you had to avoid blocky-looking blocks that fell from the ceiling. I'm pretty sure 30% of my code was GOTO statements.”

Artist's rendition of the fearsome dragon! Or possibly an angry frog. We're not really sure.

Jonathan Rochelle, Director, Product Management, also used BASIC to create his own game. “[It was] an interactive graphic which had a space ship shooting downward at growing sticks. It was on an Atari 800 using the joystick and was not at all fun to play after the first 30 seconds.” But although technical sophistication wasn’t always in reach, the possibilities excited our engineers.

The “first person driving game” Product Manager Eric Anderson created was essentially a square car and a horizon line, but he could see the potential. “It took me forever to create obstacles (more squares) that came towards my car. Once that was working, I was filled with excitement. The possibilities! I got my car moving left to right. Then I adjusted speed (the rate at which obstacles moved down from horizon). Then I added colors, wheels on my car, and the shape of the obstacles. I couldn't stop!”

We also learned programmers are a pretty dedicated bunch when it comes to seeing their inventions come to life. Global Field Marketing Program Manager Sowmya Ramakrishnan wrote her own C++ code at 15 to sort numbers. “Back then laptops didn't exist,” she tells us, “and we got one hour in a week to access computers in our school lab. Three of us shared one computer. So we would write the code in our notebooks — yes, the paper ones! — before the lab and use the time in the lab to type out the code on borland editor. It was super exciting to see a black and white monitor display the string of sorted numbers!”

Eric Ness, Technical Program Manager, Site Reliability Engineering, cobbled together an 8080 based S-100 microcomputer by buying up used computer boards and repairing them. “Back in those days, most students needed to go to the computer center to use a terminal but there were also dial-up lines available. I wanted to do my computer assignments from the comfort of my own apartment so I wrote a terminal emulator program in 8080 assembly language. My program did a reasonable job of emulating a VT-100 and could also echo the data to a printer. This program was a big time saver during my last year of school.”

Some young programmers used their budding skills to assist their parents. Douglas Dollars, Product Roadmap Program Manager, wrote an application launcher for his mom using AppleScript on an LC III. “Apple’s usability was no match for six large icons offering direct access to jigsaw puzzles and photos.”

Of course, sometimes our dedicated programmers were perhaps a bit too dedicated for their parents’ likes. “In third grade my uncle gave us his used Macintosh SE, showed me how to use QuickBASIC to make my own games and gave me a copy of ‘Creating Adventure Games On Your Computer,’” explains Brad Svee, Head of Solutions, Americas West, GCP. “I followed the guide, made my own adventure game, but changed a lot of how the game flow worked, and had to translate some of the example code from regular BASIC to QB. The last game I made was huge and amazing, and I was super proud of myself — but that was short lived. My game had somehow managed to overwrite a large portion of the 20mb hard drive, corrupting components of the OS and overwriting my mom's TurboTax files. Many tears and $1000+ later, she got some of her files back and the computer worked again, but I was relegated back to the Commodore-64 for any programming I wanted to do.”

Bill Prin, Developer Programs Engineer, came up with a creative way to convince his mom he was using his computer time for constructive uses. “I was trying to learn to make games with QBasic, but my mom limited me to an hour a day on the family computer since she thought I was just playing games. So I made a program that filled the screen with ‘I Love You, Mom!’ in different colors and sizes, which made her lift the restriction. Then my computer privileges were promptly revoked again when I deleted her dissertation draft trying to install Linux."

Here are more stories from our Google Engineers. We’d like to thank everyone who contributed their memories. Happy Programmer’s Day, everyone. See you next year.