Secret handling has been abstracted away from the framework for everything I worked on; usually our deployment system would mount secrets as a file system and then you read them as a file of key->value pairs. That, or they were just set as environment variables. I guess the framework could provide a standardized secret service, but I usually just write that myself
Not saying you shouldn't, but part of the point of a framework is all the things you don't have to write yourself.
What I like about (say) Rails secret handling is that the secrets file is an encrypted file in the repo itself. This makes it so that you can easily check out and run different versions of the repo from different times and not have to worry about that one time you renamed an envvar or something. Secrets get version controlled together with the app. The autogenerated .gitignore even includes patterns for the key files so you have to go out of your way to check them into the repo. The downside is that merging encrypted files can be a right pain in the arse, for example when two devs added different secrets in different branches.
I feel that web frameworks should be flexible enough that the CI/CD system can put things like secrets into files without worrying about the particular framework that's consuming them. If you don't write the secret service in the web framework, you have to write the secret manager in CI/CD to convert formats or what have you. Something I dislike about spring boot is how spring-y everything has to be.
> CI/CD system can put things like secrets into files
This sounds horrible. Why does specifically your CI/CD need to know those things?
This also sounds like your CI/CD system is "too smart" and your build process is "dumb pipes", what I believe to be a unsupportable, unmaintainable anti-pattern - if people can't build/test things on their own machine, things are likely not repeatable/reproducible at all and you're one CI/CD issue away from losing your project.
> Something I dislike about spring boot is how spring-y everything has to be.
I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done?
> This sounds horrible. Why does specifically your CI/CD need to know those things?
You set it up so that production secrets are kept in that store and are only accessible by a 1 or 2 high level people. Developers don't have access to production secrets, only dev or staging, which live on their own machines and are lower security risk
> if people can't build/test things on their own machine
I don't see why they wouldn't be able to build/test on their own machine. You just have a different secrets store and keys than the CI/CD does
> I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done?
Yes I hate this. I want to be able to decide how properties are loaded, not rely on some ethereal state managed behind the scenes and not be able to see if it's loading properly. If I want to use their terrible resources/config file, I'll specify that in middleware/startup
