you should only let the instance access the secret it requires.
Deleted Comment
you should only let the instance access the secret it requires.
At scale, you can very granularly define policies for each secret. When a secret is accessed, it is done so through a user or application identity. Each access is also logged.
That means that each application got a ServiceAccount (SA) and each user got a username/password. Based on your identity, you get access to specific secrets from Vault.
That being said, I will also be the first one to recognize that PLENTY of workloads are not made to run on Kubernetes. Sometimes it is way more efficient to spawn an EC2/GCE instance and run a single docker container on it. It really depends on your use-case.
If I had to run a relatively simple app in prod I would never use Kubernetes to start with. Kubernetes starts to pay itself off once you have a critical mass of services on it.
Sad to see that start to change, but I'm also kind of optimistic for one reason: there's just so damned much audio content out there that it is people's attention, not audio content, that is scarce. I don't think platforms have the upper hand in audio content the way that, say, Netflix does. I think that's why platforms like Luminary haven't really taken off.
The same thing happened with decentralized websites and blogs.then everyone got attracted by the managed platforms and now the web is more centralized than ever.
Now it moves to a walled garden with content unavailable to the outside world.
Deleted Comment
Elected officials unfortunately don't have that much incentive to hire the "cheapest" company as the debt will be incurred over the next 100 years while they will be long gone.
They probably hire the company that they feel will give them the least amount of trouble, which is the easiest to navigate or that will do something for them in exchange. It's the "not my money" issue at play.