How to secure services with SKE and Secret Manager (part 2 of security blog series)

[cghsystems]

In our customer & prospect conversations and POVs, we are hearing more and more frequently about RBAC & security patterns. People want to know how to manage their secrets, and provide promises access to the appropriate secrets for each team. RBAC concerns are both around securing the platform cluster, access to promises and access to resources.

Note

RBAC is out of scope for this blog

This miro board describes our recommended approach to this pattern. We want to write up a blog to explain this pattern to people using Kratix on docs.kratix.io

Done When

Blog written that describes how someone would implement the pattern in the blog with Vault, and other cloud providers equivalent (e.g. AWS Secrets manager)

• Blog has been reviewed by @cghsystems & @catmo-syntasso (if they are around), and someone from CA if not
• Blog published on syntasso.io/blog
• CA informed so they can share/shoutabout/whatever they need to do

CA informed so they can share/shoutabout/whatever they need to do
See GACC for more information

[catmo-syntasso]

Consider external secrets as well as a tool (speak to @kirederik )

[catmo-syntasso]

Q: is there anything actually SKE specific about this?

[cghsystems]

The orchestration of Service-to-service security is non-trivial and is DFV. Making the non-trivial trivial is something we would charge for. Secret stores need to be setup and configured correctly — which we could offer as Promises, reducing the surface area-of-attack of services through policy injection and service-to keystore comms would be handled by aspects which would be SKE only. All of the patterns to be discussed in the blog are possible in the OSS but we could make it easy via SKE. The initial idea of putting this on the Syntasso website was to hint support for security (not quite a painted door) to see who contacts us about it.

RE External secrets is one tool that we could include in anything architecture and it‘s something we could potentially commercially Promise.