fireproofsocks

fireproofsocks

I wanted to solicit the community’s knowledge/experience/recommendations on this one…

Let’s say you’re working with an application that gets deployed to production and you rely on a configuration provider (e.g. secrets_manager_provider | Hex but it doesn’t particularly matter which one).

The problem this solves is that now you can inject sensitive values directly into your Application’s process dictionary. Yay!

However, this creates a new problem: the Application process dictionary no longer has a single source of truth. We don’t know its state! With the introduction of a custom configuration provider, we no longer have a nice mapping from simple config files to Application values.

If we were relying on just runtime.exs, we could easily enforce that certain values be supplied by the environment, e.g.

import Config

config :my_app, :something, System.fetch_env!("SOMETHING")

And that creates a strong contract with the environment: the app will not start unless it is properly configured. This is the approach I leaned into with the dotenvy and it has worked well.

But with a configuration provider, we can’t take the same approach… we might not even use runtime.exs. So we have to move our “defenses” out of the configuration files and retreat into the application itself to verify that our app is configured properly.

Even if our app favors the use of Application.fetch_env!/2 over get_env/3 that’s no guarantee that it has the values it needs when it starts. With the use of the custom configuration provider, we can no longer guarantee that our Application’s process dictionary is in a good state.

How do we defend against this? We could put some code into our app’s start/2 function, e.g. something like:

  @impl true
  def start(_type, _args) do

    Application.fetch_env!(:my_app, :something)  # <-- blow up before start

    children =
      [...]
   # ...

But that feels redundant.

What are other ways to guard against this? Am I missing a trick here? Thanks in advance!

Showing Posts 1 to 4

evadne

evadne

For me, a non-issue, just be careful

I’d choose whatever that is clear and rely on the infrastructure & telemetry to roll back bad deploys — for example: if the app does not start and pass health checks within X seconds in Y tries then fail the container.

Unlikely you’d churn configuration 10 times a day or even 10 times a week/month

LostKobrakai

LostKobrakai

That sounds like an issue with the config provider. If it cannot enforce failing if expected values are available I‘d look into adding that functionality or look at alternatives.

Iirc ˋruntime.exsˋ is also consumed by a ConfigProvider, just one included with elixir instead of third party. All the constraints you can put on your system with ˋruntime.exsˋ should be replicatable with a third party config ConfigProvider as well.

fireproofsocks

fireproofsocks OP

How though? With runtime.exs , you have that explicit call to something like

config :my_app, :something, System.fetch_env!("SOMETHING")

It would be one thing if an alternate config provider were taking the place of the config files entirely, but in my experience, the alternate config providers get used in addition to the regular config files. Best case scenario (as far as I understand this) would be to devote similar (i.e. non-DRY) code that would evaluate the output from that other config provider. You end up duplicating your “configuration contract” to vet the values provided by the alternate configuration provider.

fireproofsocks

fireproofsocks OP

Can you say more about that? The problem I’m seeing is that the code that would prevent a bad deploy is in the config files. But when a value enters via a configuration provider, there’s no visibility and no visible code that vets those values.

— All posts loaded —

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 91898 914
New
AstonJ
The obligatory hello world thread! Who are you and where are you from? :stuck_out_tongue:
4616 55835 594
New
byu
@chrismccord : I just saw the Extract AGENTS.md from Phoenix.new into phx.new generator commit to the phoenix project. My initial shotgu...
New
arcanemachine
I was working on an Ecto migration and I needed a timestamp. So, for the nth time, I looked up the different data types for timestamps, a...
New
alexslade
Fly’s CEO posted this recently - Turn And Face The Strange · The Fly Blog It says that Fly is going all-in on sprites, which is a worry ...
New
Herve37
We’re evaluating API mocking tools for OpenAPI-based projects and would love to hear what other teams are using. We’re particularly inte...
New
matt-savvy
Is there a word for the ~> symbol used in Version strings? Do you also just call it a Squiggle Arrow™ ?!
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge &amp; Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
ausimian
Emily is an Elixir library that runs Nx computations on Apple’s MLX. Install it as the default Nx backend and Nx, defn, Axon, Nx.Serving,...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews