Secure Credential Management

Welcome to the first lesson of the Developer Security & Observability course. In this lesson, we will focus on secure credentials management using Google Cloud Secret Manager and the Google Cloud client library for Python.

Credentials are pieces of sensitive information, such as usernames, passwords, or API keys, that allow applications to access resources like databases or external services. If these credentials are not protected, they can be stolen or misused, leading to security breaches.

Google Cloud provides tools to help you manage credentials safely:

• Google Cloud Secret Manager lets you store, manage, and retrieve secrets securely.
• The Google Cloud client library allows your applications to interact with Google Cloud services using authenticated requests.

By the end of this lesson, you will know how to store a secret in Google Cloud Secret Manager and retrieve it securely in your application using the client library.

Before we dive in, let's understand how Google Cloud credentials work with the client libraries.

When you use a Google Cloud client library to interact with GCP services, it needs credentials to authenticate your requests. The client library looks for credentials in several places, in this order:

1. Environment variables (GOOGLE_APPLICATION_CREDENTIALS)
2. Application Default Credentials (ADC) configured on your machine
3. Service accounts (when running on Google Cloud services like Compute Engine, Cloud Run, or Cloud Functions)
4. Other configured sources

In this practice environment, credentials are pre-configured for you. However, understanding the credential chain is important for deploying your applications securely in production.

Production Best Practice: In production environments running on Google Cloud infrastructure (like Compute Engine instances), you should use service accounts instead of static credentials. Service accounts provide temporary credentials automatically, eliminating the need to store long-term access keys in your code or configuration files. We'll discuss this more at the end of the lesson.

Let's start by learning how to store a secret, such as database credentials, in Google Cloud Secret Manager using Python and the Google Cloud client library.

First, we need to import the necessary libraries. We will use the Google Cloud Secret Manager client library to interact with GCP and json to handle our secret data.

import json
from google.cloud import secretmanager

• google.cloud.secretmanager is the Google Cloud client library for Secret Manager. It allows us to interact with Secret Manager.
• json helps us format our secret data as a JSON string.

Now, let's use this function to get our database credentials and print the host.

if __name__ == "__main__":
    secret = get_secret(PROJECT_ID, "app-db-credentials")
    print("Secret host:", secret["host"])

• This code retrieves the secret and prints the value of the host field.

Example Output:

Secret host: db.example.com

Important Security Warning: We print the host field in this example because hostnames are typically not considered sensitive information. However, never print, log, or display sensitive data like passwords, API keys, or tokens - even temporarily or for debugging purposes. Once sensitive data appears in logs or console output, it can be:

• Captured in log aggregation systems
• Stored in terminal history
• Visible in screenshots or screen sharing
• Persisted in log files that may be backed up or shared

Instead, when debugging, you can print confirmation that the secret was retrieved successfully:

secret = get_secret(PROJECT_ID, "app-db-credentials")
print("Secret retrieved successfully")
# Use secret["username"] and secret["password"] in your application
# but never print them

Let's define the secret we want to store. For example, database credentials:

PROJECT_ID = "your-project-id"
SECRET_ID = "app-db-credentials"
payload = {
    "username": "appuser",
    "password": "S3cureP@ss!",
    "host": "db.example.com"
}

• PROJECT_ID is your Google Cloud project ID.
• SECRET_ID is the name we will use to refer to this secret in Google Cloud.
• payload is a dictionary containing our sensitive information.

Important Security Warning: The credentials shown in this example ("appuser", "S3cureP@ss!", etc.) are for illustration purposes only. Never commit real credentials to version control repositories, configuration files, or application logs - even if they seem like "sample" or "test" credentials. Once committed, credentials can be discovered in git history even after deletion. Secret Manager is designed to store your actual secrets securely; the code examples here demonstrate the API usage, but in practice you would store real, sensitive credentials that must never appear in your codebase.

Now, let's store the secret in Google Cloud Secret Manager. This involves two steps: creating the secret and then adding a version with the secret data.

Understanding Replication: When you create a secret, you need to specify a replication policy, which determines where your secret data is stored and replicated across Google Cloud regions. The two main options are:

• Automatic replication: Google Cloud automatically replicates your secret across multiple regions for high availability. This is the simplest option and what we'll use.
• User-managed replication: You specify exact regions where the secret should be stored, giving you more control over data locality.

For most applications, automatic replication is recommended as it provides good availability without requiring you to manage specific regions.

# Create the secret
parent = f"projects/{PROJECT_ID}"
secret = client.create_secret(
    request={
        "parent": parent,
        "secret_id": SECRET_ID,
        "secret": {"replication": {"automatic": {}}},
    }
)

# Add a secret version with the payload
secret_data = json.dumps(payload).encode("UTF-8")
version = client.add_secret_version(
    request={"parent": secret.name, "payload": {"data": secret_data}}
)
print("Created:", version.name)

• client.create_secret creates a new secret in Google Cloud.
• parent specifies the project where the secret will be created.
• secret_id is the name of the secret.
• replication defines how the secret should be replicated. We use {"automatic": {}} for automatic replication across regions.
• client.add_secret_version adds the secret data as a new version.
• The response contains information about the created secret, including its resource name.

Example Output:

Created: projects/123456789012/secrets/app-db-credentials/versions/1

Now, your secret is safely stored in Google Cloud Secret Manager.

Once your secret is stored, you need a way for your application to retrieve it securely. The Google Cloud client library makes this straightforward.

Here's how the secure retrieval flow works:

┌─────────────────────────────┐
│   Your Application          │
│   (Python + GCP library)    │
│                             │
│  ┌───────────────────────┐  │
│  │ GCP Credentials       │  │
│  │ (configured via       │  │
│  │  Application Default  │  │
│  │  Credentials)         │  │
│  └───────────┬───────────┘  │
└──────────────┼──────────────┘
               │
               │ Authenticated Request
               │ (using credentials)
               ▼
    ┌─────────────────────┐
    │  Google Cloud       │
    │  Secret Manager     │
    │                     │
    │  • Stores secrets   │
    │  • Returns values   │
    └─────────────────────┘

Key Points:

1. Your application uses the Google Cloud client library to make authenticated requests
2. The client library automatically uses available GCP credentials (from the credential chain)
3. Secret Manager validates the credentials and returns the secret if authorized
4. No secrets need to be stored in your application code

Let's write a function that fetches the secret from Google Cloud Secret Manager.

def get_secret(project_id, secret_id):
    name = f"projects/{project_id}/secrets/{secret_id}/versions/latest"
    response = client.access_secret_version(request={"name": name})
    secret_data = response.payload.data.decode("UTF-8")
    return json.loads(secret_data)

• get_secret takes the project ID and the secret ID.
• name specifies which version of the secret to retrieve (we use latest for the most recent version).
• client.access_secret_version fetches the secret from Google Cloud using the authenticated client.
• The secret is returned as bytes, so we decode it to a string and then use json.loads to convert it back to a Python dictionary.

Now, let's use this function to get our database credentials and print the host.

if __name__ == "__main__":
    secret = get_secret(PROJECT_ID, "app-db-credentials")
    print("Secret host:", secret["host"])

• This code retrieves the secret and prints the value of the host field.

Example Output:

Secret host: db.example.com

In this practice environment, credentials are pre-configured for learning purposes. However, in production, you should never hardcode credentials or rely on long-term access keys stored in configuration files.

Best Practice: Service Accounts for Compute Engine

When deploying applications on Google Cloud infrastructure like Compute Engine instances, you should:

1. Create a service account with permissions to access Secret Manager
2. Attach the service account to your Compute Engine instance
3. Use the same client library code - no changes needed!

Here's how it works:

┌─────────────────────────────┐
│      Compute Engine         │
│  ┌───────────────────────┐  │
│  │   Your Application    │  │
│  │   (Python + GCP lib)  │  │
│  └───────────┬───────────┘  │
│              │              │
│  ┌───────────▼───────────┐  │
│  │   Service Account     │  │
│  │  Provides temporary   │  │
│  │  credentials via      │  │
│  │  metadata service     │  │
│  └───────────┬───────────┘  │
└──────────────┼──────────────┘
               │
               │ Authenticated Request
               │ (temporary credentials)
               ▼
    ┌─────────────────────┐
    │  Google Cloud       │
    │  Secret Manager     │
    └─────────────────────┘

Key Advantages:

• No static credentials in your code or configuration
• Automatic credential rotation - Google Cloud provides temporary credentials that expire
• Same code - the client library automatically discovers and uses the service account credentials
• Better security - credentials can't be leaked from configuration files

The client library code you've written in this lesson works identically whether using configured credentials (like in this practice environment) or service accounts (like in production on Compute Engine). The credential discovery is automatic!

In this lesson, you learned:

• Why it's important to keep credentials secure.
• How to use Google Cloud Secret Manager to store sensitive information.
• How to retrieve secrets using the Google Cloud client library with authenticated GCP requests.
• The production best practice of using service accounts on Compute Engine instead of static credentials.

You saw step by step how to create and store a secret, and how to access it securely from your application. In the next set of practice exercises, you will get hands-on experience with these concepts by writing and running code to manage secrets yourself. This will help you build secure applications on Google Cloud from the start.