One advantage of cutting out the middle-man when sharing secrets (See: Config Replication) is empowering secret-owners to rotate secrets on their own time and without having to involve application owners.
For instance, suppose our DBA, Karen, wants to safely rotate some high power mongo credentials owned by the
service account. If following best practicies,
message-processor application will only have access to the
/app/message-processor namespace. Typically DBAs like Karen
would not and should not need direct access to this application namespace as these credentials
would be shared with the
message-processor from their secure location in Karen's DBA namespace.
So for clarity, Karen maintains the credentials here:
And through Config Replication, these credentials have been shared here:
message-processor is actively using these credentials so we cannot disable the old credentials. To perform a safe
swap we'll want to perform the equivalent of a 'blue/green' credential rotation.
Suppose the currently active user is:
Now Karen creates new set of credentials with identical permissions as the above set:
Both of these users now exist with identical permissions. Karen then replaces the user & password in its source location:
This will trigger automatic replication to the config destination. That might be all that is necessary; however, in most
cases services do not auto-reload their configurations after initial bootstrap. Karen would then need to trgger a redeploy
message-processor service. Once the new deploy has successfully rolled-out,
Karen can safely deactivate
Done! No developer involvement necessary (though a quick Slack message would probably be appreciated).
As you might imagine, this process is very easy to automate.