[HN Gopher] Twelve-factor app anno 2022
       ___________________________________________________________________
        
       Twelve-factor app anno 2022
        
       Author : ecliptik
       Score  : 40 points
       Date   : 2022-05-01 15:40 UTC (2 days ago)
        
 (HTM) web link (xenitab.github.io)
 (TXT) w3m dump (xenitab.github.io)
        
       | adzm wrote:
       | I'll admit I initially thought this was about some sort of joke
       | project regarding an authentication system requiring twelve
       | factors!
        
         | lexx wrote:
         | haha, me too
        
       | jamespwilliams wrote:
       | The advice suggesting storing config in environment variables
       | isn't great security-wise if your config contains secrets. From
       | systemd docs:
       | 
       | > Note that environment variables are not suitable for passing
       | secrets (such as passwords, key material, ...) to service
       | processes. Environment variables set for a unit are exposed to
       | unprivileged clients via D-Bus IPC, and generally not understood
       | as being data that requires protection. Moreover, environment
       | variables are propagated down the process tree, including across
       | security boundaries (such as setuid/setgid executables), and
       | hence might leak to processes that should not have access to the
       | secret data.
       | 
       | The former reason is systemd-specific, but the latter isn't.
       | There are some more reasons in
       | https://movingfast.io/articles/environment-variables-conside....
        
         | SonOfLilit wrote:
         | They are also exposed to anyone who can read from
         | /proc/PID/environ, which means a simple directory traversal
         | vulnerability can translate to database credentials.
        
         | lioeters wrote:
         | I was curious what alternative is suggested besides using env
         | variables. From the linked article:
         | 
         | > Our solution thus has been to use a configuration file which
         | is managed by the server's configuration management software
         | (chef in our case). This way we can store secret keys outside
         | of the code repository, and manage them using the same tool
         | used to configure our servers. This solution, while not
         | perfect, doesn't expose our secret keys to child processes and
         | requires explicit access, which also communicates how
         | developers should work with it.
        
         | withinboredom wrote:
         | If your machine is compromised, it's only a matter of time
         | until they get the credentials anyway. Whether you have more
         | time than them is ultimately the question.
         | 
         | I don't think the vulnerability you mention here is "worth
         | working around" for most apps, where you can trust the hardware
         | and OS you're running on. For those that can't trust the OS and
         | hardware they are running on, this may be legitimate. Even
         | then, if you can't trust that, what are you doing running
         | software on it?
        
       ___________________________________________________________________
       (page generated 2022-05-03 23:00 UTC)