Why You Should Only Use Just-in-Time, Ephemeral Credentials

Introduction to Ephemeral Credentials

As the world has grown increasingly digital, application security is now of paramount importance. As organizations adopt distributed architectures, the challenge of securely managing secrets such as API keys, database credentials, and certificates has intensified. Traditional static credentials, while once sufficient, are now a significant security risk. The need for more dynamic and secure methods of secrets management has led to the adoption of ephemeral credentials.

Ephemeral credentials play a crucial role in modern security frameworks. These temporary, short-lived credentials automatically expire after a certain period, reducing the risk of unauthorized access. Their dynamic nature aligns well with the principles of Zero Trust security models, offering a robust solution for managing secrets in increasingly complex environments.

This guide explores the importance of dynamic secrets management and provides practical examples of how to create and manage ephemeral credentials in Kubernetes and AWS environments.

The Critical Need for Dynamic Secrets Management

In the context of modern, distributed architectures, static credentials introduce significant security vulnerabilities. It’s easy to accidentally expose credentials to unauthorized individuals or have them stolen by malicious actors, leading to potentially severe security breaches. As organizations scale and their environments become more complex, managing static credentials becomes increasingly difficult and error-prone.

Furthermore, compliance with regulations such as GDPR, HIPAA, and PCI DSS requires stringent control over access to sensitive information. Static credentials often fail to meet these requirements due to their long-lived nature, making it challenging to ensure secure and compliant operations. Frequent rotation and auditing of static credentials can be a cumbersome process, further exacerbating security risks.

The industry’s shift towards Zero Trust security models emphasizes the need for more dynamic access controls. With Zero Trust, one can assume that threats originate both inside and outside the network. This requires that all access to resources be carefully monitored and controlled. Ephemeral credentials, which are temporary and automatically expire, provide a solution to this challenge by offering just-in-time access to resources. This approach reduces the risk of credential misuse and aligns with the security best practices of modern architectures.

Understanding Ephemeral Credentials

Ephemeral credentials are temporary, time-bound access tokens or secrets that you can automatically revoke or expire after a specific period or usage. You can generate them on-demand, providing a secure method for granting access to resources without the need for long-term credentials. The key characteristics of ephemeral credentials include their temporary nature, auto-expiry, and the ability to be scoped to specific resources or permissions.

The primary advantage of ephemeral credentials is the reduced risk of exposure. Since these credentials are short-lived, they minimize the window of opportunity for attackers to exploit them. Additionally, ephemeral credentials enhance an organization’s security posture by ensuring that access to sensitive resources is tightly controlled and monitored.

These credentials are particularly useful in various application architectures, such as microservices, serverless environments, and CI/CD pipelines. In microservices, ephemeral credentials allow each service to authenticate independently, reducing the risk of credential leakage across services. For serverless environments, these credentials enable functions to access resources securely without the need for static keys. In CI/CD pipelines, ephemeral credentials ensure that build and deployment processes access necessary resources dynamically, minimizing the risk of exposure during the development lifecycle.

Examples of Creating and Managing Ephemeral Credentials

There are various methods one can use to create semi-ephemeral credentials with the various tools most organizations already use. Here are examples of how you might get this done using Kubernetes and AWS Lambda.

Kubernetes Example: Using emptyDir Ephemeral Volume in Kubernetes

1. Creating a Deployment with emptyDir Volume:

In this example, we’ll create a deployment where a container writes ephemeral data to an emptyDir volume. This volume is only available during the pod’s lifetime and is automatically deleted when the pod is terminated.

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ephemeral-volume-example
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ephemeral-app
  template:
    metadata:
      labels:
        app: ephemeral-app
    spec:
      containers:
      - name: app-container
        image: busybox
        command: ["/bin/sh", "-c", "echo 'This is a temporary secret' > /mnt/ephemeral/secret.txt && sleep 3600"]
        volumeMounts:
        - name: ephemeral-storage
          mountPath: /mnt/ephemeral
      volumes:
      - name: ephemeral-storage
        emptyDir: {}

2. Explanation:

• emptyDir Volume: The emptyDir volume is created when a pod is assigned to a node and exists as long as that pod is running on that node. If the pod is deleted, the data in the emptyDir is also deleted. It can be useful for storing ephemeral data that does not need to be persisted beyond the life of the pod.
• volumeMounts: In this example, the emptyDir volume is mounted at /mnt/ephemeral inside the container. The container writes a temporary secret to this directory.
• Command in the Container: The container runs a command that writes a simple secret (in this case, just a string) to a file inside the mounted emptyDir volume. The sleep 3600 command keeps the container running for an hour to simulate a long-running process.

3. Use Cases for emptyDir:

• Temporary Data Storage: emptyDir is useful for temporary data that does not need to persist across pod restarts, such as caches, temporary files, or transient data that needs to be shared between multiple containers within the same pod.
• Scratch Space: emptyDir can be used as scratch space for containers, where they can store temporary files that are not needed after the pod terminates.
• Security Considerations: While this approach is simple, it does not provide encryption or access control on the data stored in emptyDir. It’s essential to consider whether the data written to such volumes needs to be protected, especially if it contains sensitive information. Another concern is that if your pods are long-living, then you need to ensure that credentials are revoked or erased.

AWS Lambda Example: Managing Temporary Secrets for AWS Lambda Functions

• Step 1: Generate a temporary secret (e.g., an API key) using a script or AWS Secrets Manager.

bash
aws secretsmanager create-secret --name MyTemporarySecret --secret-string "$(openssl rand -base64 32)" --duration-seconds 3600

• Step 2: Configure your Lambda function to retrieve this secret at runtime.

python
import boto3

def lambda_handler(event, context):
    secret_name = "MyTemporarySecret"
    region_name = "us-east-2"

    client = boto3.client('secretsmanager', region_name=region_name)
    get_secret_value_response = client.get_secret_value(SecretId=secret_name)

    secret = get_secret_value_response['SecretString']
    # Use the secret in your function logic
    print(f"Using secret: {secret}")

• Step 3: Deploy the Lambda function, ensuring it has the necessary IAM permissions to retrieve secrets.

Explanation:

The AWS Lambda function is configured to retrieve a temporary secret from AWS Secrets Manager at runtime. This method involves the following steps:

1. Storing Secrets in AWS Secrets Manager:
   • Secrets are stored securely in AWS Secrets Manager. AWS Secrets Manager encrypts these secrets using AWS Key Management Service (KMS) keys, ensuring that the data is protected at rest.
2. Retrieving Secrets at Runtime:
   • The Lambda function uses the AWS SDK (in this case, boto3 for Python) to retrieve the secret when the function is invoked. This means that the secret is not hardcoded in the Lambda function’s code or environment variables, reducing the risk of accidental exposure.
3. Using the Secret:
   • Once retrieved, the secret is used within the Lambda function’s logic, for example, to authenticate API requests or connect to a database.

This method ensures that the secret is only available when needed and is not stored within the Lambda function’s environment, which reduces the attack surface.

Although the secret is retrieved only at runtime, they do not get automatically revoked or erased by default. While the Lambda execution environment is ephemeral, and any in-memory data is discarded after execution, the validity of the retrieved credentials remains unchanged until you manually rotate or revoke them in AWS Secrets Manager.

The Need for an External Secrets Manager

An external secrets manager is generally superior for handling ephemeral, just-in-time secrets management compared to native Kubernetes, AWS, and other systems because it offers centralized, consistent management across diverse environments. External tools are designed to dynamically generate, rotate, and revoke secrets in an automated fashion, ensuring that credentials are always fresh and reducing the risk of exposure. They integrate seamlessly with multiple platforms, providing a unified approach to secrets management that enhances security, compliance, and operational efficiency.

Additionally, external secret managers often come with advanced features like fine-grained access controls, audit logging, and policy-based automation, which are more robust than what native systems offer. This makes them ideal for complex, multi-cloud and hybrid environments where maintaining security consistency and minimizing the risk of stale or over-privileged credentials are critical.

We already use too many tools and applications in our organizations, and they are all scattered between various teams, making it that much more difficult to stop potential leaks. By abstracting secrets management from individual platforms, external solutions provide a more scalable and secure approach to handling ephemeral secrets.

The Akeyless Approach to Ephemeral Credentials

Akeyless is a cloud-native, SaaS-based secrets management platform designed to provide robust and scalable solutions, including ephemeral credentials. As a fully managed service, Akeyless eliminates the need for organizations to maintain complex on-premises infrastructure. It offers, instead, a seamless and secure way to manage secrets across diverse environments. Its cloud-native architecture ensures that secrets are accessible from anywhere. In addition, with high availability and built-in redundancy, it meets the demands of modern, distributed applications.

One of Akeyless’s standout features is its ability to dynamically generate secrets on demand. This includes automated secret creation and revocation, which are critical for maintaining security in dynamic environments. With Akeyless, secrets can be generated just-in-time for specific use cases and automatically revoked after a defined period, significantly reducing the risk of credential exposure. This automated management ensures that secrets remain secure throughout their lifecycle without requiring manual intervention.

Akeyless simplifies the implementation of ephemeral credentials by integrating seamlessly with major DevOps tools and platforms. This includes CI/CD, Code Management, and Configuration Management to Infrastructure Automation, Log Forwarding, and Kubernetes.

For instance, in Kubernetes, Akeyless can dynamically inject secrets into pods at runtime. This ensures that applications always use up-to-date credentials and ensure that credentials are revoked. Similarly, Akeyless integrates with CI/CD pipelines, such as with Github and GitLab. This enables secure secrets management throughout the development and deployment process. In cloud environments, Akeyless can generate temporary IAM credentials or API keys, with automatic management and deletion. This reduces operational overhead and enhances security.

Through these integrations, Akeyless provides a unified and simplified approach to managing ephemeral credentials. This makes it easier for organizations to adopt best practices while maintaining agility and security in their workflows.

Let’s look at how this is actually done.

Dynamic Secret Example

Here is a simple example of how to create a MySQL dynamic secret and fetch temporary credentials with Akeyless using our Python SDK:

Create a MySQL Dynamic Secret and Fetch Temporary Credentials

python
import requests

# Step 1: Authenticate and obtain a token
auth_url = "https://<your-gateway-url>:8081/auth"
auth_payload = {
    "access-type": "access_key",
    "access-id": "<your-access-id>",  # Replace with your Access ID
    "access-key": "<your-access-key>"  # Replace with your Access Key
}
headers = {
    "accept": "application/json",
    "content-type": "application/json"
}

try:
    auth_response = requests.post(auth_url, json=auth_payload, headers=headers)
    auth_response.raise_for_status()  # Raises an error for HTTP codes 4xx/5xx
    token = auth_response.json().get("token")
    print(f"Authentication successful. Token: {token}")
except requests.exceptions.HTTPError as http_err:
    print(f"HTTP error occurred during authentication: {http_err}")
    print(f"Response content: {auth_response.text}")
    exit()
except Exception as err:
    print(f"Other error occurred during authentication: {err}")
    exit()

# Step 2: Use the token to create a MySQL dynamic secret
url = "https://<your-gateway-url>:8081/dynamic-secret-create-mysql"

payload = {
    "name": "mysql-dynamic-secret",  # Name of the dynamic secret
    "mysql-host": "<your-mysql-host>",  # MySQL host
    "mysql-port": "3306",  # MySQL port
    "mysql-username": "<your-mysql-root-user>",  # MySQL username
    "mysql-password": "<root-user-mysql-pass>",  # MySQL password
    "mysql-dbname": "<your-mysql-db-name>",  # MySQL database name
    "user-ttl": "60m",  # Time-to-live for the user
    "token": token  # Use the token obtained from authentication
}

try:
    response = requests.post(url, json=payload, headers=headers)
    response.raise_for_status()  # Raise an error for bad responses
    print("Dynamic secret created successfully!")
    #print(response.json())  # Print response in JSON format
except requests.exceptions.HTTPError as http_err:
    print(f"HTTP error occurred: {http_err}")
    print(f"Response content: {response.text}")
except Exception as err:
    print(f"Other error occurred: {err}")

# Step 3: Fetch temporary user credentials
url = "https://<your-gateway-url>:8081/get-dynamic-secret-value"

payload = {
    "timeout": 15,
    "name": "mysql-dynamic-secret",
    "target": "mysqlTarget",
    "token": token
}
headers = {
    "accept": "application/json",
    "content-type": "application/json"
}

response = requests.post(url, json=payload, headers=headers)

print("Here are your temporary credentials:")
print(response.text)

Note that when creating a Dynamic Secret, we set the time-to-live (user-ttl above) of the user created in MySQL. Hence, when that length of time passes, Akeyless actually goes back into the MySQL instance and deletes that temporary user.

The Akeyless Difference

Akeyless stands out as a superior and more secure secrets management solution due to its implementation of true Zero-Knowledge Encryption through the use of a Gateway that includes a customer fragment. We built this on a mechanism we call DFC^TM, where the platform generates the encryption key in multiple fragments. We then store these fragments securely on different clouds. The last piece, however, we call the customer fragment, because the customer keeps it within their environment inside their Gateway.

This architecture ensures that even Akeyless, as the service provider, has no access to the sensitive data and secrets managed within the platform, providing an unparalleled level of security and privacy for its users.

The Gateway, deployed on-premises or within the customer’s cloud environment, never combines the fragments at any time – neither during encryption or decryption – ensuring that the full key never exists in one place as a whole.

This approach significantly reduces the risk of unauthorized access or data breaches, as even in the unlikely event of a compromise within Akeyless’s infrastructure, the attacker would not be able to decrypt any secrets without the customer fragment. Additionally, the Gateway ensures that all cryptographic operations occur within the customer’s controlled environment, aligning with strict compliance and regulatory requirements.

By leveraging this Zero-Knowledge architecture, Akeyless provides a secure, cloud-native solution that gives customers full control over their data while benefiting from the scalability and convenience of a SaaS platform, which makes Akeyless an ideal choice for organizations that prioritize security, privacy, and compliance, particularly in highly regulated industries.

Conclusion

Ephemeral credentials offer a robust solution for managing secrets in today’s complex, distributed architectures. Their temporary nature significantly reduces the risk of credential exposure. This aligns with the principles of Zero-Trust security models and ensure tighter control over access to sensitive resources. As organizations increasingly adopt microservices, serverless environments, and CI/CD pipelines, the importance of dynamic secrets management becomes even more critical.

Both Kubernetes and AWS provide mechanisms to manage ephemeral credentials, but they come with limitations. Kubernetes’ emptyDir volumes and AWS Lambda’s integration with Secrets Manager are useful. However, they lack built-in features for automatic credential revocation or granular access control. This is where external secrets management solutions, such as Akeyless, shine. Akeyless not only simplifies the management of ephemeral credentials across various platforms. It also enhances security with its Zero-Knowledge Encryption model. This model ensures that even Akeyless cannot access the sensitive data, offering unparalleled security and compliance.

By adopting solutions like Akeyless, organizations can streamline their secrets management processes. They can also ensure that credentials are automatically generated, managed, and revoked without manual intervention. This approach not only reduces operational overhead. It also strengthens the overall security posture, making it a critical component of modern application security strategies.

---

Ready to see it for yourself? Get a custom demo of Akeyless to address all your Kubernetes secrets management use cases.