For those that haven’t heard about Tink, it is a very powerful library for using cryptographic primitives. This library is used within Google and is maintained by a small team of incredbly smart cryptographers to incorporate best cryptographic practices.

In this tutorial, we’ll implement a common solution to a problem that GPG typically solves, but do it all with Tink. That problem is asymmetric encryption; i.e. Alice wants to send a secret message to Bob, so she encrypts a message with Bob’s public key, then Bob decrypts it with his private key.

Image for post
Image for post
Asymmetric encryption with key stored in Secret Manager

Tink’s documentation is generally great, but the operational aspect is sometimes missing. That is, how do I use this end-to-end in practice? …

TL;DR: Generating and distributing service account keys poses severe security risks to your organization. They are long-lived credentials that are not automatically rotated. These keys can be leaked accidentally or maliciously allowing attackers to gain access to your sensitive GCP resources. Additionally, when used actions cannot be attributable back to a human. You don’t actually have to download these long-lived keys. There’s a better way!

Image for post
Image for post

Service Accounts, OAuth2 and You

For some background, almost every change you want to make in Google Cloud from creating a GKE cluster to reading from a GCS bucket is handled using an API. This API is authenticated using the OAuth2 protocol, which basically means there’s a short lived (1 hour default) access token attached to every authenticated request. If you’re familiar with the whole “Sign in with Google” popup, that’s OAuth2 hard at work authenticating you with your Google credentials. Once you’re authenticated, an access token is attached to all your API requests whether you’re using gcloud, terraform, SDKs, or the console. In Google Cloud, we use a lot of automation and web services which similarly need those tokens, but robots aren’t very good at opening browsers and typing in passwords so they need some sort of verifiable identity. …

Image for post
Image for post

A long time ago in an internet far far away, the Okta plugin for Vault was the only way to use your Okta credentials to get into Vault. It still works very well, allowing you to associate a Vault policy with an Okta user or group but it has some limitations:

  1. The Okta auth method does not support all MFA methods, only Okta Push Verify
  2. It requires Vault have access to an Okta API token
  3. It doesn’t allow you to assign users to Vault as an Okta chicklet

More recently, the kind folks at HashiCorp released a fantastic new auth plugin that works with JWT/OIDC which means it also works with Okta. This tutorial will show you how authenticate to Vault using Okta with OIDC and be granted a Vault token based on your Okta group. …


Ryan Canty

Cloud Security Engineer at Google Cloud http://github.com/onetwopunch

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store