I'm going to talk in rather vague terms here as I'm not talking about one specific implementation, but the concept here:
The idea is that there is some system that is capable of provisioning access credentials and automatically providing them to resources based on their identity. This could be your CI runner, scping auth credentials into known locations when the system is deployed. This could be your cloud provider, using something like IAM roles and the metadata service. This could be your kubernetes cluster, providing a mount inside the container. Ideally this system is also capable of rotating these credentials too.
Then you have another system which is able to verify those credentials to give access. If you're fancy, you're doing something like mTLS on all your internal network calls so every endpoint on the other hand is verifying every other endpoint, but it could also be something like secrets manager or vault just dispensing out API keys based on your systems credentials provided in the previous step.
There is definitely a tradeoff here that the system that manages the credentials effectively has the keys to the kingdom and could if compromised provide identity for anything. Some companies respond to this by delegating the whole lot to their cloud provider, which has its own risks of course.
The advantages of doing this are basically:
- You only have to manage one set of credentials manually (whatever your system managing the instance/service identity is)
- You can then easily make credentials for things accessing each other short lived if you know they're getting replaced periodically, which helps reduce the impact of breaches/leaks
- Depending on your specific implementation, you can avoid secrets hitting disk entirely, which further helps reduce the impact of breaches.
The idea is that there is some system that is capable of provisioning access credentials and automatically providing them to resources based on their identity. This could be your CI runner, scping auth credentials into known locations when the system is deployed. This could be your cloud provider, using something like IAM roles and the metadata service. This could be your kubernetes cluster, providing a mount inside the container. Ideally this system is also capable of rotating these credentials too.
Then you have another system which is able to verify those credentials to give access. If you're fancy, you're doing something like mTLS on all your internal network calls so every endpoint on the other hand is verifying every other endpoint, but it could also be something like secrets manager or vault just dispensing out API keys based on your systems credentials provided in the previous step.
There is definitely a tradeoff here that the system that manages the credentials effectively has the keys to the kingdom and could if compromised provide identity for anything. Some companies respond to this by delegating the whole lot to their cloud provider, which has its own risks of course.
The advantages of doing this are basically:
- You only have to manage one set of credentials manually (whatever your system managing the instance/service identity is)
- You can then easily make credentials for things accessing each other short lived if you know they're getting replaced periodically, which helps reduce the impact of breaches/leaks
- Depending on your specific implementation, you can avoid secrets hitting disk entirely, which further helps reduce the impact of breaches.