I feel like "secure" is more along the lines of the end goals, not engineered attributes.

I agree it's very important (see chapter 8 of Cloud Native Infrastructure) but many of the ways to make something secure are combinations of other attributes. From my experience the best you can do to secure any infrastructure and application is make the them verifiable (operability + observibility), agile to respond to vulnerabilities, and provisioned with least privilege. No amount of securing would have made you not vulnerable to spectre, heartbleed, or other critical vulnerabilities found in the past few years. Your best hope was if you could audit your systems (verifiable) and have an automated build/deploy pipeline (agile) to patch/replace impacted components. Even if the components were only provisioned with the minimum privileges needed vulnerabilities could still have huge impact and make your systems susceptible to hacking.

The only secure attributes not covered by one of the existing attributes is least privilege access. How that is implemented depends a lot on the application and environment. Kubernetes' RBAC and SPIFFE are examples for how to secure systems but I feel like saying "Cloud Native is least privilege" doesn't clarify anything. Does that mean least privilege for services? How about user accounts? Does that mean I need to enable SElinux/AppArmor? What about VPCs and overlay networks?

Maybe we can think of a way to clarify how to say "least privileged" without being too vague and sticking to engineered attributes and not end goals or product specific implementations.

--
Justin Garrison
justingarrison.com

On Sun, Feb 4, 2018 at 2:15 PM, Michael Gasch <embano1@...> wrote:

Great thread and I totally agree what's been discussed and summarized so far here.
Do you mind incorporating a notion on security in the definitions?

Something like:

• Secure by design
  • Zero-trust (vs. solely relying on underlying/external components, e.g. firewalls)
  • Incorporating and complying with high encryption standards of data in transit and at rest (especially secrets)
  • Enforcing RBAC, this is including authorization/authentication/accounting primitives
  • Only exposing minimal attack surface (L4-7)
  • The list goes on

?

Btw: I am German and can help thinking about more prescriptive "Attribut- und Zustandsbeschreibungen"  :D