You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We’re using Sops in multi-tenant environments (https://dev.to/camptocamp-ops/argo-cd-secrets-management-using-sops-1eke), but, unless I’m mistaken, we’re vulnerable to the confused deputy problem, where one tenant can trick the system running Sops into decrypting another tenant’s encrypted file.
If I understand correctly, authenticated encryption with associated data (for example using AWS KMS security context) could protect us. However, there seems to be no way to pass the security context to Sops at decryption time, and relying on the security context in the encrypted file fails at protecting us against the confused deputy problem.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hello,
We’re using Sops in multi-tenant environments (https://dev.to/camptocamp-ops/argo-cd-secrets-management-using-sops-1eke), but, unless I’m mistaken, we’re vulnerable to the confused deputy problem, where one tenant can trick the system running Sops into decrypting another tenant’s encrypted file.
If I understand correctly, authenticated encryption with associated data (for example using AWS KMS security context) could protect us. However, there seems to be no way to pass the security context to Sops at decryption time, and relying on the security context in the encrypted file fails at protecting us against the confused deputy problem.
Am I missing something here?
Beta Was this translation helpful? Give feedback.
All reactions