Requirements and Considerations¶
When developing Ingress solutions for the Machine Identity Management Control Plane, you should always build with the goal of certification in mind.
TLS Protect For Kubernetes Certification
Certified solutions see increased adoption from users. Find out more!
Minimum Requirements¶
- The solution must automate the delivery/consumption of any machine identity required to enforce the security of workloads protected by the Ingress Controller.
- The solution must cope with both the creation and renewal of machine identities.
- The solution must perform any necessary updates or reconfigurations to bindings/associations attached to the machine identity.
- The solution must source its machine identities from Kubernetes secrets.
Some clarifying remarks on the final point. The use of TLS secrets is commonplace for persisting X.509 certificates but organizations have been known to restrict or even prohibit their use. The Ingress specification mandates the use of secrets when you wish to entrust your Ingress Controller with the task of TLS termination. If this conflicts with your internal policies then the use of Ingress for TLS termination is not an option and you should consider something like the cert-manager csi-driver. The csi-driver solution, which is commonly used to enforce mTLS between workloads, eliminates the use of secrets and necessitates TLS termination closer to your workloads.
Focus on UX
The best solutions will require little, if any, human interaction after initial configuration.
Security Considerations¶
The Kubernetes Ingress specification provides for TLS enforcement on a per routing rule basis, but this security feature is optional. This is somewhat regrettable in light of the modern browser security requirements and your pursuit of zero-trust by default. Security should be uppermost among your concerns.
As the developer of a Ingress Controller solution, you will need to:
- support only Ingress rules with explicit provision for TLS (by default).
- provide full support for modern OpenID Connect Identity Providers (e.g. Auth0, GitHub, Google, Okta, etc.)
These considerations are in addition to any policy enforcement (e.g. minimum cipher strength) applied by TLSPK's approver-policy-enterprise, the Venafi TLS Protect products or upstream Certificate Authorities.
Building a Better User Experience¶
The user experience should be as painless as possible and the expectation is that your target product should:
- Be easy to install, preferably via Helm
- Be highly available
- Enable the user to deploy an MVP into your cluster with little or no configuration requirements
- Provide comprehensive logs for diagnostic purposes
- Export metrics in the common Prometheus format (e.g. network traffic, latency, error rates, utilization, request counts)
- Provide complete/appropriate documentation, both online and within CRDs when applicable
Conforming to the these requirements will greatly enhance the user experience, providing additional value to teams and organizations.
Success Stories¶
Existing solutions that fit within this pattern: