In talking to over 80+ organizations at Armory.io, We've found that security is top concern for enterprises big and small. Many companies handle sensitive data and services for their customers so it's critical that they're able to secure their code and infrastructure for their customers.
We've taken the feedback from our 80+ discussions and incorporated it into Enterprise Spinnaker from Armory.io which we've demo'd before this blog post and we'll go into further details here today.
It all starts with an understanding of your organization and how code reaches production. In many organizations we see engineering teams build code as a first step.
From there it goes through the QA teams to ensure quality before it goes to production. This is typically done manually at most companies we've spoken to but we've seen automation included as well.
After the QA gives the green light it goes into production where responsibility is handed over to operations teams to oversee its health.
To handle the different teams and responsibilities Spinnaker has roughly 4 areas of potential isolation. We'll start from the largest level which is just instance level isolation. This could mean that each team would have their instance.
The next level of isolation would be project level isolation. Projects are a grouping of applications and clusters. This would be an entire stack like You can create groupings of users to only have access to certain projects while allowing operations to have access to all projects.
From there you can have application level isolation. Applications are typically a single service or micro-service, like user management. You may want to have developer or QA users locked down to a particular service.
The last level of potential isolation within Spinnaker is a deployment pipeline so that you can have certain users tied down
Many of these aspects are still under active development by the Spinnaker community but this might give you a glimpse as to how you might want to think about securing access to your resources.