Forem: Roberto Guerra

GCP Notes: Configure API Gateway with Terraform

Roberto Guerra — Thu, 30 Sep 2021 16:39:09 +0000

Originally posted in https://blog.openstep.net/posts/gcp-api-terraform/

GCP API Gateway gives you more control over access to your Cloud Functions triggered by HTTP. I will explain how to configure an API Gateway and why you might want to do that.

According to GCP's documentation: "With API Gateway, you can create, secure, and monitor APIs for Google Cloud serverless back ends, including Cloud Functions, Cloud Run, and App Engine. Built on Envoy, API Gateway gives you high performance, scalability, and the freedom to focus on building great apps. Consumption-based and tiered pricing means you can better manage cost."

If you have built serverless APIs in AWS, you have more than likely used AWS API Gateway to expose your lambdas as HTTP endpoints. AWS API Gateway allows you to throttle traffic, add authentication, modify headers, etc. GCP did not have an equivalent service until 2020, and as of this writing (September 2021), it is still in beta. GCP Cloud Functions provide you with an HTTP(s) endpoint by default if they have an HTTP trigger. You can also specify if the Cloud Function is publicly exposed. However, you can not secure the endpoint, nor throttle traffic, nor use a custom domain. API Gateway also provides metrics about the endpoints (latency, error rates, etc.). If you want to keep track of what applications use your APIs, you can create API keys for each application. API Gateway then allows you to view the traffic generated by each application, and you can throttle or disable APIs using the keys instead of having to modify code.

GCP API Gateway Components

The API Gateway is made up of 3 components:
The Config
The Gateway
The API

The Config is an OpenAPI v2 document that allows you to map the Cloud Function endpoint to an API endpoint:

swagger: '2.0'
info:
  title: poe-api
  description: API Gateway for POE
  version: 1.0.0
schemes:
  - https
produces:
  - application/json
paths:
  /api/echo:
    get:
      summary: Echo
      operationId: echo
      x-google-backend:
        address: https://project-id.cloudfunctions.net/HandlerEcho
      responses:
        200:
          description: Successful response
          schema:
            type: string

This example deploys an API that forwards all requests to /api/echo to the Cloud Function HandlerEcho. It also only uses HTTPS, and all the endpoints return JSON.

Enabling CORS

You need to enable CORS if your APIs are accessed from a web application. Browsers restrict cross-origin HTTP requests initiate from scripts unless the response from other origins includes the correct CORS headers. I won't explain how to configure CORS on your server; that topic is out of scope, but I'll explain how to configure GCP API Gateway to work with CORS.

Configuring CORS can be annoying because you have to provide an additional path for every one of our endpoints. There is probably a better way of doing this, but I found that this works for me. You have to copy-paste the path you configured and change it to be an options request.

paths:
     /api/echo:
        get:
            summary: Echo
            operationId: echo
            x-google-backend:
                address: https://project-id.cloudfunctions.net/HandlerEcho
            responses:
                200:
                    description: Successful response
                    schema:
                        type: string
        options:
            summary: Echo
            operationId: echo
            x-google-backend:
                address: https://project-id.cloudfunctions.net/HandlerEcho
            responses:
        200:
            description: Successful response
            schema:
                type: string

API Keys

GCP API Gateway allows you to secure & monitor your APIs in several ways. APIs can be throttled and disabled based on the API Key that they used. You can create an API key for a web application and another key for machine-to-machine access. If you notice that the latter makes more requests than expected, that API Key can be throttled or disabled without affecting the web application.

You need to configure API Keys in your config file and also using the GCP console. In your config file, add a top-level field:

security:
- api_key: []
securityDefinitions:
    api_key:
        type: apiKey
        name: apiKey
        in: query

This snippet says that all endpoints expect a query parameter called apiKey. There are other types of security that API Gateway provides, but I won't cover them in this post.

The second step is to go to the GCP console, navigate to APIs & Services, then click on Enable APIs and Services. This will take you to a page where you should search for the API you created and enable it. Then return to the APIs & Services page and click on Credentials and Create Credentials. Then select API Key. GCP assigns an autogenerated name to the key, but you should change it and customize it. Click on the name of the generated key, and change the name to something that describes the service using the key. The string under API Key is what customers of your APIs should use. You can also further restrict access by type of application and HTTP referrers if the key will be used by a web application. Finally, click on Restrict Key and select your API from the drop-down.

Prevent access to the backend

You can force everyone to use your API only via the API Gateway by disabling unauthenticated access to your backend. The API Gateway will use a service account to access the backend. However, if your backends are inspecting the Authorization header for JWT tokens, then your endpoints will stop working. This happens because the API Gateway will inject its own JWT token on that header. You will need to use a different header to provide the JWT token that your application needs. Maybe something like X-Authorization, but whatever you use, be consistent and make sure to document it.

Deploying with Terraform

You will use the Terraform Google provider (https://registry.terraform.io/providers/hashicorp/google/latest/docs) for deployment. You need three resources to configure an API Gateway:

Config: google_api_gateway_api_config
API: google_api_gateway_api
Gateway: google_api_gateway_gateway

The Config holds the OpenAPI document that describes the endpoints that will be served.
The Gateway defines an external URL that API clients will use to access the API.

provider "google" {
  project = var.project_id
  region  = var.region
  zone    = var.zone
}

locals {
  api_config_id_prefix     = "api"
  api_id                   = "your-api-id"
  gateway_id               = "your-gateway-id"
  display_name             = "API Display Name"
}

resource "google_api_gateway_api" "api_gw" {
  provider     = google-beta
  api_id       = local.api_gateway_container_id
  project      = var.project_id
  display_name = local.display_name
}

resource "google_api_gateway_api_config" "api_cfg" {
  provider             = google-beta
  api                  = google_api_gateway_api.api_gw.api_id
  api_config_id_prefix = local.api_config_id_prefix
  project              = var.project_id
  display_name         = local.display_name

  openapi_documents {
    document {
      path     = "openapi.yaml"
      contents = filebase64("openapi.yml")
    }
  }
  lifecycle {
    create_before_destroy = true
  }
}

resource "google_api_gateway_gateway" "gw" {
  provider = google-beta
  region   = var.region
  project  = var.project_id


  api_config   = google_api_gateway_api_config.api_cfg.id

  gateway_id   = local.gateway_id
  display_name = local.display_name

  depends_on   = [google_api_gateway_api_config.api_cfg]
}

You should be able to run terraform plan to verify the configuration, and terraform apply to deploy.

Conclusion

You can use GCP API Gateway to have more fine-grained control over your APIs. You saw how to do this using the OpenAPI specification and how to use API Keys to protect your endpoints. You can also leverage Terraform for declaring your API Gateway as code.

References

The Terraform Provider https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/api_gateway_api
OpenAPI Extensions https://cloud.google.com/endpoints/docs/openapi/openapi-extensions#x-google-jwt-locations
API Gateway Official Docs https://cloud.google.com/api-gateway/docs

Go Notes: Parsing Claims in Firebase JWT Token

Roberto Guerra — Thu, 04 Mar 2021 15:27:04 +0000

I struggled to parse the Firebase JWT Claims. Because claims may contain strings, maps, and arrays, the claims field type is an []interface{}. In this example, one of the claims was a list of permissions. Permissions themselves were just an array of strings. Go does not know that it is an array string, and it is impossible to convert it directly. Instead, we need an intermediary conversion.

The Firebase Token struct is defined as:

// Token represents a decoded Firebase ID token.
//
// Token provides typed accessors to the common JWT fields such as Audience (aud) and Expiry (exp).
// Additionally it provides a UID field, which indicates the user ID of the account to which this token
// belongs. Any additional JWT claims can be accessed via the Claims map of Token.
type Token struct {
    AuthTime int64                 `json:"auth_time"`
    Issuer   string                `json:"iss"`
    Audience string                `json:"aud"`
    Expires  int64                 `json:"exp"`
    IssuedAt int64                 `json:"iat"`
    Subject  string                `json:"sub,omitempty"`
    UID   string                   `json:"uid,omitempty"`
    Firebase FirebaseInfo           `json:"firebase"`
    Claims   map[string]interface{} `json:"-"`
}

The field we are concerned with is Claims. It is a map of interfaces. It will hold additional information that is added upstream when a user is created. We can assume that one of these pieces of data added is a roles field that consists of an array of strings. E.g.: ["role1", "role2", "role3"]

After extracting the claims, and accessing the roles field, we need to convert the interface type to []interface{}, because we can't convert directly from interface to []string:

roles := claims["roles"]
var roles []string
for _, p := range claims["roles"].([]interface{}) {
   roles = append(roles, p.(string))
}

The takeaway for me was that interface{} can't be converted to []someType{}. We can only convert from interface to another type if the shapes are similar.

Reference:
https://golang.org/ref/spec#Type_assertions

Go Notes: Auth0 validation for AWS Lambda Pt 2

Roberto Guerra — Tue, 03 Mar 2020 03:58:20 +0000

We will use the auth0 library we forked previously, to create an AWS Lambda(lambda) authorizer. This authorizer will indicate whether a request is authorized or denied. We'll also deploy the authorizer using the serverless framework and write a basic unit test for the authorizer.

Requirements

Basic understanding of what jwt is.
Some basic Go knowledge.
Some basic AWS Lambda knowledge.
Some basic serverless knowledge.

Step 1: Configure the Lambda Authorizer

The lambda authorizer is defined in the serverless.yaml file under the functions block. It is no different from any other lambda, except that we won't provide any events. The Auth0 library we will use makes sure that the issuer and the audience match what is in the jwks key. We also need to provide the url that the auth0 client will use to download the jwks key. We'll provide these values as environment variables:

functions:
  authorizer:
    handler: bin/authorizer
    environment:
      AUTH_ISSUER: ${self:custom.authorizer.TOKEN_ISSUER}
      AUTH_AUDIENCE: ${self:custom.authorizer.AUDIENCE}
      JWKS_URI: ${self:custom.authorizer.JWKS_URI}

custom:
  stage: ${opt:stage, "dev"}
  authorizer: ${file(../../config/authorizer.${opt:stage,self:provider.stage}.yml)}

bin/authorizer is the eventually compiled asset that will be uploaded to AWS.

The authorizer variables are maintained in a yaml file under a config folder following the pattern: authorizer.<stage>.yml. Example content:

TOKEN_ISSUER: https://yourapp.auth0.com/
AUDIENCE: your-audience
JWKS_URI: https://yourapp.auth0.com./.well-known/jwks.json

Step 2: Initialize the Auth0 Client and logger

We'll initialize the auth0 client and the logger in the init function of our main.go. The reason for doing this is that the AWS Lambda go runtime will keep an instance of our program running after it finishes so that it can re-use them when a request hits the warm instance. This allows us to limit instantiations:

package main

import (
    log "github.com/sirupsen/logrus"
    "github.com/uris77/auth0"
)

var auth0Client auth0.Auth0

func init() {
    // Instantiate an auth0 client with a Cache with the capacity for
    // 60 tokens and a ttl of 24 hours
    auth0Client = auth0.NewAuth0(60, 518400)
    log.SetFormatter(&log.JSONFormatter{})
    log.SetOutput(os.Stdout)
}

The logger is configured to format its output as JSON and to write to Stdout. Lambda will push all stdout to Cloud Watch. This allows us to view our logs as structured data.

Step 3: Gather Preconditions

The preconditions for this authorizer are that we need to have values for AUTH_AUDIENCE, JWKS_URI and AUTH_ISSUER:

func Authorizer(ctx context.Context, evt events.APIGatewayCustomAuthorizerRequest) (events.APIGatewayCustomAuthorizerResponse, error) {
    if len(os.Getenv("JWKS_URI")) < 1 {
        panic("The required JWKS_URI is missing")
    }
    jwkUrl := os.Getenv("JWKS_URI")

    if len(os.Getenv("AUTH_AUDIENCE")) < 1 {
        panic("The required AUTH_AUDIENCE is missing")
    }
    aud := os.Getenv("AUTH_AUDIENCE")

    if len(os.Getenv("AUTH_ISSUER")) < 1 {
        panic("The required AUTH_ISSUER is missing")
    }
    iss := os.Getenv("AUTH_ISSUER")

        log.WithFields(log.Fields{
        "event":       evt,
        "jwkUrl":      jwkUrl,
        "aud":         aud,
        "iss":         iss,
        "auth0Client": auth0Client,
        "context":     ctx,
    }).Info("Authorizer triggered")

}

If all the preconditions are true, we log the initial state. This can be helpful when troubleshooting because we might want to know what were the inputs and the initial state to the authorizer.

Step 4: Validate the token

The authorization token is in the events.APIGatewayCustomAuthorizerRequest parameter of the authorizer:

type APIGatewayCustomAuthorizerRequest struct {
    Type               string `json:"type"`
    AuthorizationToken string `json:"authorizationToken"`
    MethodArn          string `json:"methodArn"`
}

The token is a string and also includes the Bearer string.

    jwt, err := auth0Client.Validate(jwkUrl, aud, iss, evt.AuthorizationToken)

The auth0 client will return a jwt token or an error when we validate a token against the jwkUrl and the audience and issuer.

The authorizer needs to return an ApiGatewayCustomAuthorizerResponse, which will indicate to the Api Gateway if the request is authorized. The type is defined as:

type APIGatewayCustomAuthorizerResponse struct {
    PrincipalID        string                           `json:"principalId"`
    PolicyDocument     APIGatewayCustomAuthorizerPolicy `json:"policyDocument"`
    Context            map[string]interface{}           `json:"context,omitempty"`
    UsageIdentifierKey string                           `json:"usageIdentifierKey,omitempty"`
}

The PolicyDocument is what we use to authorize the request. It will include an Iam Policy Statement:

// APIGatewayCustomAuthorizerPolicy represents an IAM policy
type APIGatewayCustomAuthorizerPolicy struct {
    Version   string
    Statement []IAMPolicyStatement
}

// IAMPolicyStatement represents one statement from IAM policy with action, effect and resource
type IAMPolicyStatement struct {
    Action   []string
    Effect   string
    Resource []string
}

Step 5: Error Handling

If validation failed, we can create a response with a policy that will deny the request:

if err != nil {
        r := events.APIGatewayCustomAuthorizerResponse{
            PolicyDocument: events.APIGatewayCustomAuthorizerPolicy{
                Version: "2012-10-17",
                Statement: []events.IAMPolicyStatement{
                    {
                        Action:   []string{"execute-api:Invoke"},
                        Effect:   "Deny",
                        Resource: []string{"arn:aws:execute-api:*"},
                    },
                },
            },
        }

        log.WithFields(log.Fields{
            "jwt":      jwt,
            "err":      err,
            "response": r,
        }).Error("Token Validation Failed")

        return r, nil
    }

It is a good idea to also log the error in case we need to do some troubleshooting.

We can also make the policy more specific and use the arn for the request:


r := events.APIGatewayCustomAuthorizerResponse{
            PolicyDocument: events.APIGatewayCustomAuthorizerPolicy{
                Version: "2012-10-17",
                Statement: []events.IAMPolicyStatement{
                    {
                        Action:   []string{"execute-api:Invoke"},
                        Effect:   "Deny",
                        Resource: []string{evt.methodArn},
                    },
                },
            },
        }

Step 6: Happy Path

When validation succeeds, we only need to make two minor changes: provide a PrincipalId and change the Policy Document so that it accepts the request:

resp := events.APIGatewayCustomAuthorizerResponse{
        PrincipalID: jwt.Subject(),
        PolicyDocument: events.APIGatewayCustomAuthorizerPolicy{
            Version: "2012-10-17",
            Statement: []events.IAMPolicyStatement{
                {
                    Action:   []string{"execute-api:Invoke"},
                    Effect:   "Allow",
                    Resource: []string{evt.methodArn},
                },
            },
        },
    }

    log.WithFields(log.Fields{
        "jwt":      jwt,
        "response": resp,
    }).Info("Successfully Validated Token")

    return resp, nil

Conclusion

An AWS Lambda Authorizer is the mechanism used by Api Gateway to authorize requests. It will provide an APIGatewayCustomAuthorizerRequest to the authorizer. This request contains both the token and the method's arn.

We can validate the request's token with the auth0 client, and return the corresponding IAM Policy Document, which will indicate to Api Gateway if the request is allowed to be executed.

Go Notes: Auth0 validation for AWS Lambda

Roberto Guerra — Tue, 28 Jan 2020 02:08:47 +0000

I found myself migrating a serverless service written in node to Go, and needed to write a lambda authorizer. An authorizer is simply an AWS Lambda that the API Gateway will invoke to verify if the request is authorized.

The AWS Go SDK has a type for the API Gateway Request that the authorizer will receive. The authorizer I need is very simple for now. It will only concern itself with validating the JWT token. This token is represented by AuthorizationToken in the APIGatewayCustomAuthorizeRequest.

type APIGatewayCustomAuthorizerRequest struct {
    Type               string `json:"type"`
    AuthorizationToken string `json:"authorizationToken"`
    MethodArn          string `json:"methodArn"`
}

I looked around for a library that I could leverage and found github.com/apibillme/auth0. However, it didn't quite suit my use case. The function signature for validating a token is:

Validate(jwkURL, audience, issuer string, req *http.Request) (*jwt.Token, error)

The main obstacle to me using it is that the authorizer won't be receiving an http.Request. I needed a function where the token was a string:

Validate(jwkURL, audience, issuer, jwtToken string) (*jwt.Token, error)

So I cloned the repo and made the changes I needed. Since the most recent activity in that repo was over a year ago, I figured that it was being actively maintained. But I still found some value in the code, so I decided to fork it and publish my own version.

The other interesting feature of this code is that it also includes a cache. The tokens are stored in the cache and for every request, the cache is inspected, and if the token is found in the cache, then we don't need to re-validate that token. So, there was one minor update I decided to make. The original code base requires that a cache be created explicitly before we can validate a token:

New(128, 5)
Validate(jwkEndpoint, audience, issuer, ctx)

I was confused initially because I didn't know what New was doing. So, I created an Auth0 type, along with a constructor:

type Auth0 struct {
    cache cache.Cache
}


// Create a new Auth0 client.
// keyCapacity indicates the maximum number of keys the Cache will hold.
// ttl is the time to live in seconds for keys to live in the Cache.
func NewAuth0(keyCapacity int, ttl int64) Auth0 {
    globalTTL := time.Duration(ttl)
    Cached := cache.New(keyCapacity, cache.WithTTL(globalTTL*time.Second))
    return Auth0{cache: Cached}
}


// Validate - validate with JWK & JWT Auth0 & audience & issuer for net/http
func (a Auth0) Validate(jwkURL, audience, issuer, jwtToken string) (*jwt.Token, error) {
    // process token
    tokenParts := strings.Split(jwtToken, " ")
    token, err := verifyBearerToken(tokenParts)
    if err != nil {
        return nil, err
    }
    return a.processToken(token, jwkURL, audience, issuer)
}

Now using it is pretty simple:

func handler(ctx Context, req APIGatewayCustomAuthorizerRequest) APIGatewayCustomAuthorizerResponse {
    //Retrieve the issuer, audience and the JWKS_URI from the environment.

    token := req.AuthorizationToken
    auth0 := NewAuth0(128, 60)
    jwtToken, err := auth0.Validate(JWKS_URI, audience, issuer, token)
    // Use the jwtToken to create the response
}

I'm still trying to figure out how to unit test this library. My main struggle is creating a token and a key for the tests using Go. I'll write down my notes for the next blog post, before documenting how to eventually create the APIGatewayCustomAuthorizerResponse

Go Notes: Example Tests

Roberto Guerra — Tue, 21 Jan 2020 02:25:49 +0000

Go's Example Tests are a great tool for documenting the expectations of our code. They are conveniently integrated with godocs, making the docs have more context and actual runnable examples. These tests provide a quick overview of what the code is supposed to be doing in a manner that is easily digestible for the reader without needing to understand the inner workings.

What are Example Tests?

In Example Tests, we print out the result of a function that we want to test, and we indicate the expected output as comments:

func ExampleTest() {
    fmt.Println("Hello World!")
    // Output:
    // Hello World!
}

If we can't determine the order of the output of a test, we can use Unordered output instead of Output:

func ExampleUnorderedTest() {
    unordered := afunc()
    fmt.Println(unordered)

    // Unordered output:
    // d
    // c
    // a
    // b

}

Naming Conventions

The Go community seems to have settled on two naming conventions for the example file names. Both conventions can be found in the standard library. The first one follows the pattern xxx_example_test.go. This can bee seen in the example tests for stringer: https://github.com/golang/go/blob/master/src/fmt/stringer_example_test.go.

The second pattern is example_xxx_test.go. This pattern is prevalent in the sort package of the standard library: https://github.com/golang/go/tree/master/src/sort.

# Summary
Example tests are a useful tool for documenting our code. They are kept relevant because they are run as tests and are embedded in the "godocs" for easy consumption.

Go Notes: Omitting empty structs

Roberto Guerra — Fri, 10 Jan 2020 23:30:29 +0000

Go provides a convenient way of marshaling and unmarshaling structs by using struct field tags. This gives us the benefit of not letting the Go naming convention to leak into the JSON structure, and it also doesn't force us to use a non-idiomatic naming convention for our APIs that will be consumed outside our team.

Let's draft an example. We are modeling a census application that will capture basic information about people.

type Person struct {
    Name string `json:"name"`
    Address string `json:"address"`
    DateOfBirth string `json:"dob"`
    Occupation string `json:"occupation"`
}

With this struct, we can encode and decode the following JSON:

{
 "name": "Rob Pike",
 "address": "On a Street somewhere, in some city",
 "dob": "1970-01-01",
 "occupation": "engineer"
}

If we didn't know the address, then that field would be unmarshaled to the default value. In this case, it would be an empty string. Hence, this struct:

Person{
    Name:        "Rob Pike",
    Address:     "",
    DateOfBirth: "197-01-01",
    Occupation:  "engineer",
}

would be marshaled to:

{
 "name": "Rob Pike",
 "address": "",
 "dob": "1970-01-01",
 "occupation": "engineer"
}

There are times we don't want non-existent fields to be set to their zero values when unmarshalling them. This can be configured by using omitempty:

type Person struct {
    Name string `json:"name"`
    Address string `json:"address,omitempty"`
    DateOfBirth string `json:"dob"`
    Occupation string `json:"occupation"`
}

Now this person:

Person{
    Name:        "Rob Pike",
    Address:     "",
    DateOfBirth: "197-01-01",
    Occupation:  "engineer",
}

would be marshaled to:

{
 "name": "Rob Pike",
 "dob": "1970-01-01",
 "occupation": "engineer"
}

We also want to record how many children a person has. We can modify Person like this:


type Person struct {
    Name        string   `json:"name"`
    Address     string   `json:"address"`
    DateOfBirth string   `json:"dob"`
    Occupation  string   `json:"occupation"`,
    Dependent   Children `json:"dependent,omitempty"`,
}

type Children struct { Name string `json:"name, omitempty"`}

I know that someone can have more than one child, but I'm struggling coming up with didactic examples.

If we want to unmarshal a JSON struct with no dependent:


{
 "name": "Rob Pike",
 "dob": "1970-01-01",
 "occupation": "engineer"
}

Our struct will try to create a zero value for Children, in this case, it will be a struct with empty fields:

Person{
    Name:        "Rob Pike",
    Address:     "",
    DateOfBirth: "197-01-01",
    Occupation:  "engineer",
    Dependent:   Person{Name: ""},

}

There are instances where we would actually want this to be nil. For example, if we are pushing this to an elasticsearch index that has mappings that do not allow empty strings for name. For this use case, we have to use pointers.

type Person struct {
    Name        string   `json:"name"`
    Address     string   `json:"address"`
    DateOfBirth string   `json:"dob"`
    Occupation  string   `json:"occupation"`,
    Dependent   *Children `json:"dependent"`,
}

type Children struct { Name string `json:"name, omitempty"`}

Our unmarshaled person with no dependent now looks like this:

Person{
    Name:        "Rob Pike",
    Address:     "",
    DateOfBirth: "197-01-01",
    Occupation:  "engineer",
    Dependent:   nil,

}

Summary

Use omitempty to avoid marshaling and unmarshaling non-existent fields. However, if a field is a struct, we should use pointers.

Go AWS Notes: KMS - Decryption

Roberto Guerra — Mon, 06 Jan 2020 19:21:21 +0000

I use KMS for serverless apps when I want to put some secrets as an environment variable (Yes, I know SSM exists). I use the serverless app and the serverless-kms-secrets (https://github.com/nordcloud/serverless-kms-secrets) for encrypting secrets and making it convenient for using them in a lambda.

After installing the plugin, we can encrypt a secret in the command line:

sls encrypt -n MY_SECRET -v my-password

The plugin readme (https://github.com/nordcloud/serverless-kms-secrets) goes into more detail on how to use it.

Decrypting the secret can be rather simple with Go, but I initially found it a bit tricky when I first tried to use it. My first attempt was something like this:

// Create an AWS Session
sess, _ := session.NewSession(&aws.Config{
        Region: aws.String("us-west-2"),
    })  
svc := kms.New(sess)
mypassword := os.Getenv("MY_SECRET")    
input := &kms.DecryptInput{CiphertextBlob: []byte(mypassword)}  
_, err := svc.Decrypt(input)

But this kept throwing an InvalidCiphertextException exception. The AWS documentation states that this exception occurs because "the specified ciphertext, or additional authenticated data incorporated into the ciphertext, such as the encryption context, is corrupted, missing, or otherwise invalid." The documentation also mentions that the encrypted secret is bas64 encoded. This means that I have to base64 decode the encrypted secret and use that as the value for the CiphertextBlob in the DecryptInput:

encpass := os.Getenv("MY_SECRET")
password, _ := base64.StdEncoding.DecodeString(encpass)

The resulting output is of type DecryptOutput that looks something like:

type DecryptOutput struct {
   _ struct{} `type:"structure"`

   // ARN of the key used to perform the decryption. This value is returned if
   // no errors are encountered during the operation.
   KeyId *string `min:"1" type:"string"`

   // Decrypted plaintext data. When you use the HTTP API or the AWS CLI, the value
   // is Base64-encoded. Otherwise, it is not encoded.
   //
   // Plaintext is automatically base64 encoded/decoded by the SDK.
   Plaintext []byte `min:"1" type:"blob" sensitive:"true"`
}

The clear secret is now accessible through the Plaintext field.

P.S.: Remember to do the appropriate error handling.