DEV Community: Eduardo Reyes

Keep Secrets Out of the State: Terraform's Ephemeral Resources

Eduardo Reyes — Sat, 21 Jun 2025 00:56:30 +0000

Securing Sensitive Data in Terraform with Ephemeral Resources

Terraform state files contain detailed information about your infrastructure, including sensitive data like passwords, API keys, and authentication tokens.

While Terraform offers various methods to manage this sensitive information, the introduction of ephemeral resources in version 1.10+ provides a powerful new approach to keeping secrets out of your state files entirely.

In this post, we'll explore how ephemeral resources work, why they're important for security, and provide a practical example using AWS RDS database creation with automatic password rotation.

Consider this, you've misconfigured the S3 bucket that holds your Terraform state, allowing for anonymous access, now everyone can see your sensitive data.

If you've configured your state S3 bucket with anonymous access you have bigger problems to worry about than what is written here.

Your first priority with dealing with Terraform is securing your state file, you can use a well-protected S3 bucket, Terraform Cloud, Consul, and more.

Ephemeral resources are a kind of resource that is made to keep one-time data outside of the Terraform state, this is perfect for sensitive material – though there are some factors to consider.

Documentation

Ephemeral Resources

Ephemeral Block Reference

Practical Example

Creating a database with RDS is a common enough pattern, so let's use that to show how to use ephemeral blocks to create a password with Terraform while avoiding having the secret stored in the Terraform state and allowing us to rotate the secret with a simple version bump (or a time_rotating resource).

provider "aws" {}

terraform {
  required_version = ">= 1.10"

  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 6.0"
    }

    random = {
      source = "hashicorp/random"
      version = "~> 3.0"
    }

    time = {
      source = "hashicorp/time"
      version = "~> 0.3"
    }
  }
}

versions.tf

ephemeral "random_password" "database" {
  length = 16
}

resource "time_rotating" "password" {
  rotation_minutes = 10
}

resource "aws_db_instance" "this" {
  allocated_storage = 10
  db_name = "awesome_db"
  engine = "mysql"
  instance_class = "db.t3.micro"
  password_wo = ephemeral.random_password.database.result
  password_wo_version = time_rotating.password.unix
  skip_final_snapshot = true
  username = "awesome_username"
}

main.tf

Let's break down the example, first, the ephemeral resource is declared, it behaves exactly the same as a standard resource, the only difference is that its value is not known after apply by Terraform.

Instead, it uses a foo_version property to track if the ephemeral value needs to change – once you change the version there's no way of getting the old value back.

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_db_instance.this will be created
  + resource "aws_db_instance" "this" {
      + allocated_storage = 10
      + copy_tags_to_snapshot = false
      + db_name = "awesome_db"
      + engine = "mysql"
      + instance_class = "db.t3.micro"
      + password_wo = (write-only attribute)
      + password_wo_version = (known after apply)
      + region = "us-east-1"
      + skip_final_snapshot = true
      + username = "awesome_username"
    }

  # time_rotating.password will be created
  + resource "time_rotating" "password" {
      + rotation_minutes = 10
      + unix = (known after apply)
    }

Plan: 2 to add, 0 to change, 0 to destroy.

terraform plan -out planfile (trimmed some data out of the output)

After the instance is created it won't detect changes for ten minutes (how we defined it in the time_rotating resource).

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

terraform plan -out planfile

Now, we'll let the time_rotating resource lapse by waiting ten minutes and check again with a new speculative plan.

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the
last "terraform apply" which may have affected this plan:

  # time_rotating.password has been deleted
  - resource "time_rotating" "password" {
        id = "2025-06-27T22:23:36Z"
      - unix = 1751063616 -> null
        # (9 unchanged attributes hidden)
    }

Unless you have made equivalent changes to your configuration, or ignored the
relevant attributes using ignore_changes, the following plan may include
actions to undo or respond to these changes.

─────────────────────────────────────────────────────────────────────────────

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create
  ~ update in-place

Terraform will perform the following actions:

  # aws_db_instance.this will be updated in-place
  ~ resource "aws_db_instance" "this" {
      ~ password_wo_version = 1751063616 -> (known after apply)
        # (72 unchanged attributes hidden)
    }

  # time_rotating.password will be created
  + resource "time_rotating" "password" {
      + rotation_minutes = 10
    }

Plan: 1 to add, 1 to change, 0 to destroy.

terraform plan -out planfile

We can then apply the plan to rotate the database password with a new random one, terraform apply -auto-approve planfile, rotating static db credentials is one way of using it, maybe not the most useful but it's one of the only resources that support write-only attributes at the moment, but now you know how to use them, other providers might have better support.

Limitations and Considerations for Ephemeral Resources

While ephemeral resources offer significant security benefits, there are some important limitations to keep in mind:

Limited Provider Support : Currently, only certain providers and resources support write-only attributes, which are necessary for ephemeral resources to function properly. Always check provider documentation for compatibility.
Debugging Challenges : Since values aren't stored in state, debugging can be more difficult when issues arise with ephemeral resources.
State Recovery : If you need to import or recover infrastructure, ephemeral resources add complexity since their values aren't available in state backups.
Team Coordination : When multiple team members work with infrastructure containing ephemeral resources, additional coordination may be needed since values can't be referenced from the state.
Requires Terraform 1.10+ : Older Terraform versions don't support this feature, so you'll need to ensure your environment is updated.

Despite these limitations, ephemeral resources provide a valuable security enhancement for handling sensitive data in Terraform when implemented appropriately.

Laravel Requests data transformation

Eduardo Reyes — Sat, 08 Feb 2020 15:33:08 +0000

Few people know that you can piggyback on a Form Requests to transform the data you receive before getting it into the controller - this is super useful to keep controllers clean and to make validation easier.

Imagine someone sends you a line-separated email list to your API without doing any client-side transformations on their side (this can easily happen by just sending the value of a textarea) so you’ll probably want to validate that data, and use it down the line in a format that’s easier for your program to handle (array/Collection).

First thing we need to do is create our Form Request and our controller.

php artisan make:controller -i EmailsController
php artisan make:request UserEmailsRequest

this will create a new file under App\Http\Requests, this file should be injected into your controller instead of the default request so that the validation and data transformations can happen auto-magically.

<?php

namespace App\Http\Controllers;

use App\Http\Requests\UserEmailsRequest;
use Illuminate\Http\JsonResponse;
use Illuminate\Http\Response;

class EmailsController extends Controller
{
    /**
     * Handle the incoming request.
     *
     * @param UserEmailsRequest $request
     * @return JsonResponse
     */
    public function __invoke(UserEmailsRequest $request): JsonResponse
    {
        return response()->json([], Response::HTTP_NOT_IMPLEMENTED);
    }
}

To use this controller in your routes/api.php file just add it like this:

Route::post('somewhere', 'EmailsController');

The __invoke function in the controller gets called automatically by Laravel whenever you don’t specify a function to call.

Now, to the interesting part - this are all the basic functions you’ll want to override in your form request.

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class UserEmailsRequest extends FormRequest
{
    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
        ];
    }

    /**
     * Prepare the data for validation.
     *
     * @return void
     */
    protected function prepareForValidation()
    {
    }
}

$request->emails looks like this "foo@bar.com\nbar@foo.com,foobar@barfoo.com" and we want to transform it into an array and validate that each one of the values is also a valid email, the final array will look like this:

[
    "foo@bar",
    "bar@foo.com",
    "foobar@barfoo.com",
]

We will start by transforming the data using the prepareForValidation function, this is called before validation is even attempted as the name suggests, in here we can transform the request and validate against the transformed data (the original data is still available through the $this->get('emails') function)

/**
 * Prepare the data for validation.
 *
 * @return void
 */
protected function prepareForValidation()
{
    // This is where the magic happens, the data from the key 'emails' will be overwritten
    // with the return value of the formatEmails function.

    $this->merge([
        'emails' => $this->formatEmails($this->emails),
    ]);
}

/**
 * Transforms the request from a list of emails separated by a \n to an array of emails.
 *
 * @param string $emails
 *
 * @return array
 */
protected function formatEmails(string $emails): array
{
    // Simple transformation in here, explode the string by the delimiter, then filter
    // all the empty lines and then trim the empty values from the final array.
    // this is not production ready code so don't use it.

    return collect(explode("\n", $emails))
        ->filter(static function ($email) {
            return !empty($email);
        })
        ->map(static function ($email) {
            return trim($email);
        })->toArray();
}

Before the transformation, validating the data that was sent to us would have required to do the same transformation we just did as a custom rule, now since the data is nicely packed into a standard array we can use standard validation rules against it.

    /**
     * Get the validation rules that apply to the request.
     *
     * @return array
     */
    public function rules()
    {
        return [
            'emails' => 'required|array',
            'emails.*' => 'required|email',
        ];
    }
}

And that’s it! if we go back to our controller we can use $request->emails as an array now plus all the values in the array will be validated using standard laravel rules

<?php

namespace App\Http\Controllers;

use App\Http\Requests\UserEmailsRequest;
use Illuminate\Http\JsonResponse;
use Illuminate\Http\Response;

class EmailsController extends Controller
{
    /**
     * Handle the incoming request.
     *
     * @param UserEmailsRequest $request
     * @return JsonResponse
     */
    public function __invoke(UserEmailsRequest $request): JsonResponse
    {
       // do something here with your clean copy of $request->emails remember that you
       // that you can get the original request values by doing $request->get('emails')

        return response()->json([
            ['emails' => $request->emails]
        ], Response::HTTP_OK);
    }
}

Response:

{
    "emails": [
        "foo@bar.com",
        "bar@foo.com",
        "foobar@barfoo.com"
    ]
}

The response from the endpoint will be a validated json array, just as we wanted! now down the line you can use this transformed value in other methods, your one-off function that handled the transformation is tucked away into the request itself and you don’t have to add noise to your controllers - if the function you made is something you’re able to re-use for other requests then make a base request controller, drop that function in there and inherit the requests from that base controller instead, that way you’ll have access to that function wherever you need it.

Hugo and Nginx multi-stage build Dockerfile

Eduardo Reyes — Sat, 16 Jun 2018 02:20:10 +0000

Originally posted on Reyes.

After searching for a bit I was unable to find a nice pre-made Dockerfile to serve my personal site (built on top of Hugo), some of the images I found were only Hugo build steps, some others were able to serve and build the site but they pulled the FROM:ubuntu docker anti-pattern.

So here I'll describe what I'm doing on my final Dockerfile, it's a really simple Docker Multi-Stage build, the first step gets the Hugo binary and builds the site, the second one copies over the public folder of the built site and serves it using the official alpine Nginx image.

What's a multi-stage build?

With multi-stage builds, you use multiple FROM statements in your Dockerfile. Each FROM instruction can use a different base, and each of them begins a new stage of the build. You can selectively copy artifacts from one stage to another, leaving behind everything you don’t want in the final image. To show how this works, Let’s adapt the Dockerfile from the previous section to use multi-stage builds.

Docker

Hugo Build Step

FROM alpine:3.5 as build

ENV HUGO_VERSION 0.41
ENV HUGO_BINARY hugo_${HUGO_VERSION}_Linux-64bit.tar.gz

# Install Hugo
RUN set -x && \
  apk add --update wget ca-certificates && \
  wget https://github.com/spf13/hugo/releases/download/v${HUGO_VERSION}/${HUGO_BINARY} && \
  tar xzf ${HUGO_BINARY} && \
  rm -r ${HUGO_BINARY} && \
  mv hugo /usr/bin && \
  apk del wget ca-certificates && \
  rm /var/cache/apk/*

COPY ./ /site

WORKDIR /site

RUN /usr/bin/hugo

The first part FROM alpine:3.5 as build it's labeling that build step as build so that in the next step we can get artifacts from this previous image, the artifact we'll be keeping is the built site.

ENV HUGO_VERSION 0.41
ENV HUGO_BINARY hugo_${HUGO_VERSION}_Linux-64bit.tar.gz

This is pretty self-explanatory, declare the Hugo version and use it to get the binary name that we're gonna get from the official GitHub releases

RUN set -x && \
  apk add --update wget ca-certificates && \
  wget https://github.com/spf13/hugo/releases/download/v${HUGO_VERSION}/${HUGO_BINARY} && \
  tar xzf ${HUGO_BINARY} && \
  rm -r ${HUGO_BINARY} && \
  mv hugo /usr/bin && \
  apk del wget ca-certificates && \
  rm /var/cache/apk/*

set -x will give us a nice output for these commands, then we are updating the repos and installing wget and ca-certificates from the alpine repositories, after that we're building the release binary download URL from the GitHub releases page and downloading it using wget, then we're uncompressing the tar file, deleting it and moving the binary to the /usr/bin folder, after that we do some standard clean-up tasks to get the final image to the lower size we can without much effort.

COPY ./ /site

WORKDIR /site

RUN /usr/bin/hugo

Now we're copying the current directory (should be the Hugo site root folder) and moving it into /site (inside the container), next we're basically doing a change-dir to /site and the last step is the one that actually runs the Hugo binary against /site and that gets us the final /public folder with the assets that we're gonna server over Nginx.

Nginx Build Step

This one is pretty simple and it's the second and last step, we're gonna be using the official Alpine Nginx repo to get a container with the reverse-proxy installed

FROM nginx:alpine

LABEL maintainer Eduardo Reyes <eduardo@reyes.im>

COPY ./conf/default.conf /etc/nginx/conf.d/default.conf

COPY --from=build /site/public /var/www/site

WORKDIR /var/www/site

This one is really simple, we're getting the official nginx:alpine image and using it as our second build step, then I'm adding my maintainer label to the final container, copying over a Nginx configuration file over the container, the important step is this one.

COPY --from=build /site/public /var/www/site

This step is getting the public folder (the artifact we built on the first step) --from the build step of the multi-stage build and copying it over /var/www/site were Nginx will serve it as static content thanks to the basic configuration file copied earlier and then we're changing dirs into the site, so that if we want to go into the container we're already where the code is.

Final Dockerfile

FROM alpine:3.5 as build

ENV HUGO_VERSION 0.41
ENV HUGO_BINARY hugo_${HUGO_VERSION}_Linux-64bit.tar.gz

# Install Hugo
RUN set -x && \
  apk add --update wget ca-certificates && \
  wget https://github.com/spf13/hugo/releases/download/v${HUGO_VERSION}/${HUGO_BINARY} && \
  tar xzf ${HUGO_BINARY} && \
  rm -r ${HUGO_BINARY} && \
  mv hugo /usr/bin && \
  apk del wget ca-certificates && \
  rm /var/cache/apk/*

COPY ./ /site

WORKDIR /site

RUN /usr/bin/hugo

FROM nginx:alpine

LABEL maintainer Eduardo Reyes <eduardo@reyes.im>

COPY ./conf/default.conf /etc/nginx/conf.d/default.conf

COPY --from=build /site/public /var/www/site

WORKDIR /var/www/site

Building the image

This one is a really simple docker command, you should run it from the root of your Hugo site.

docker build -t some-hugo-site .

and to see the results just do:

docker run -d -p 8080:80 some-hugo-site

I recommend using traefik to expose the container to the web, take advantage of the automatic let's encrypt integration and add a http -> https redirect to get a nice TLS workflow.