My team approaches this problem by using separate identities with different access policies for doing different things. The identity can be an alternative user

My team approaches this problem by using separate identities with different access policies for doing different things. The identity can be an alternative user account (disconnected from the primary corp domain) or a service principal that does only limited set of things. For example, an alternative user account with restricted time window for access is used to even get to performing infrastructure management tasks. Then each cluster has unique service principal attached to it for pulling containers and retrieving infra-related secrets, but cannot access application-related secrets. Applications that run on clusters use completely different managed identity which doesn't have access to infra-related secrets, but has access to application-related secrets. On top of that, wherever possible, we restrict access to secrets only to GET operations, so you need to know the name of the secret beforehand in order to access it. The latter is not always possible, but if it is possible, we use it. We use a bunch of scripts that go on and create all necessary identities and set up security policies, which helps a lot with ensuring the process is fully repeatable and risks of user mistakes are mitigated.