Ease of debug when building on bespoke base container

[ianmiell]

Ease of debug when building on bespoke base container

[aidanhs]

Does it make sense to impose a strong separation between 'core' config sections (repository, host, container) and module sections? I'm thinking that module builds should never behave intentionally differently based on core config sections.

By enforcing this separation, it becomes safer (but still not completely) to serialise module configs into the container because they simply cannot contain passwords of the user. Instead they end up containing the passwords of e.g. mysql...which a user at the other end has to know anyway.

Now, assuming module configs are serialised to the container, we can secure any potentially sensitive configs by not putting them in a module. E.g. if we have com.corp.shared_folder.shared_folder and com.corp.vcs.git_login which need common ldap credentials but shouldn't have stored, we'd put them in a section called com.corp.passwords (or even just com.corp).
If either of the modules above has a requirement to use the credentials of the current user (e.g. authenticating to use the version control system), that code would be moved out of build (which only gets run once) and into start.

Which boils down to "Store all configs in container manifest", with restrictions to remove sensitive items - as noted, the only passwords left would be passwords a user needs to know anyway.

[ianmiell]

Is this still an issue with the (now-documented) config changes?

I'm aggressively closing hoping for a re-open if so.