danielfoglio
commented
4 years ago Based on team discussion we have decided to put policy management on hold until the feature is explicitly requested. We have decided to go with a default secure implementation.
Problem to solve
Managing security concerns across a Kubernetes cluster is complicated. Implementing security controls often requires that users have in depth knowledge of both Kubernetes internals and cloud infrastructure. This puts a heavy burden of knowledge on anyone trying to run an application in the cloud.
Proposal
To simplify the management of security controls (aka "policies"), we should create a service that consolidates the management of policies into a single place. This service would be a single source of truth for the security policies of both cloud infrastructure and the Kubernetes cluster.
The single source of truth should have individual settings for each of the conceptual policies that we want to control. The other management services will need to interpret these policies to take action. This service should not take any management action on its own.
For example, "Encryption at rest" may be a setting controlled by policy management. This may mean "encrypt etcd" to the cluster management service, and "encrypt EBS storage" to the cloud management service if on AWS.
Towards this goal, we need to make some design decisions for how we will accomplish this technically. This issue creates a code-level design to satisfy the requirements previously decided upon in the architecture: https://github.com/cratekube/policy-mgmt-service/blob/master/docs/requirements.md
Intended users
All users of the CrateKube system will use this component by default.
Further details
It is not required that the initial iteration for this design cover every security setting that we can think of. It is more important that we create a system that is extensible that could be used to cover all security settings in the future.
Permissions and Security
This feature is primarily a security feature. We will need to make sure that this service is both generic enough to be useful for the open source community, and is able to be used to satisfy Cisco's Infosec requirements
Documentation
None.
How can we measure success?
None.
When is this feature complete?
This feature is complete when the following items have been completed:
Links / references
Some amount of this design has already been completed, however, we were unable to come to an agreement regarding how the policy controls would work in the YAML file.