When there are multiple third party services getting used in your spring boot application. How do you manage their API creds.
Like I use Aws Secret Manager for the keys and different account level info. But after fetching in the application in runtime should we create classes to hold such info or just class variables are enough?
I'm more curious about the coding standard practices of different developers in the globe.

Eventually you need to reveal the secrets to use them. This likely has to happen in memory, so having them anywhere in memory is likely as safe as possible.

Some people go a little further and put them in an env file on the host, but this adds another point of entry (a reverse proxy could read your services secrets from disk but maybe not from memory, although this is debated)

Don't store secrets in files. Store them in a safe vault [like you do -- ASM] and fetch them whenever [preferably once in a runtime, i.e. upon startup] and keep them in-memory whereever you like [system properties, spring autowired properties, separatd class - whereever really].

I can think of 3 attack vectors to siphon secrets in-mem:
- jvm heap dump
- javaagent attaching to the jvm
- attacks on the host [network dumps, core dumps, etc.]

do NOT load secrets as env variables - they can be easily obtained if an attacker leverages any RCE vector or any other way to access the filesystem

@netikras attackers can often leverage /proc/$PID/mem anyway. Unless your system is hardened, which it should be.

The biggest attack vector is honestly people. As long as they don't know the secrets, they don't have a secrets.txt on their desktop, and you can auto expire and manually revoke them, you've done 80% of the work.

@lungdart right... tell this to my previous client (corp, LARGE one) who had leaked far more than just secrets in last year's (and the year before that) breaches.

Last year was the last drop and they started hardening the hell out of their systems. I mean, even banks don't usually go as far as they do now.

Knowing their infra, habbits, processes and all, this super-hardening makes perfect sense.

So NO, I would NOT set the bar low. People are just an entry vector. Once that's exploited, all of the internals are eventually accessible if not handled properly

@netikras getting your creds from people or from systems is the same breach level.

There's no such thing as a 100% secure system, so you can spend infinite money making it better, which will brick the economy and tank your company. So it stops somewhere.

What's more important than trying to prevent a beach, is to assume a beach is inevitable and spend resources on mitigation and recovery planning.

1) alerting/canaries
2) ensuring creds are short lived
3) ensuring creds are revocable
4) keeping your network segregated
5) keeping everything encrypted at rest and encrypted in transit
6) pen testing and phishing tests
7) threat hunting
8) shifting security left

Do the 20% of the work that gets 80% of the result first. Then do 80% of the with that gets you the next 10% to 15% of the way there.

@netikras I find the do not load them as env variables a weird one. But that is perhaps because RCE is not an IT thing?

The problem is that no matter the vault at some point the info needs to be used and it needs to be passed on/fetched. The user (app) is more likely to have a remote exploitable vulnerability. If other levers are fucked nothing matters.

It's the app can get stuff from the vault that is more dangerous because that means that it has at least some access to the vault.

@hjk101 in linux envs of any process can be easily dumped using ´cat´ from the procfs. RCE grants this access through the service endpoints. Malware in a technitian's laptop grants this access with wider scope and better privileges.

Memdumps are much more difficult to obtain [quietly].

@netikras what is RCE?

@hjk101 remote code execution

@netikras ah yeah. The thing about the app environment is that is slightly easier to unless you have some knowledge about the framework used you can probably easily probe for a variety of config/credentials in memory anywhere.

In any case I would advise to use environment variables to communicate these credentials. If you feel that they are too obvious to access by RCE you should simply unset them after loading where needed. This prevents the app (and thus RCE) from accessing the secure credential store.