Skip to main content

Cloud Native Security Tenets

This page reviews the Cloud Native Security Tenets published by TAG Security and Compliance, describes how Cadence meets them today, and explains how operators loosen security from Cadence's defaults.

How Cadence satisfies the tenets​

TenetCadence's posture
1. Security is a design requirementMutual TLS and JWT-based authorization (common/authorization) are pluggable components built into the server.
2. Secure configuration has the best UXNot fully met. TLS and authorization are both off in the stock config/development.yaml, so enabling them takes extra configuration. This is a known gap, covered below.
3. Insecure configuration is a conscious decisionNot met. The insecure configuration is the default and requires no decision. An operator has to add a tls: or authorization: block to turn security on, which is the reverse of the tenet's intent (secure by default, with an explicit opt-out). Uber's own production deployments always run with TLS and authorization enabled.
4. Insecure-to-secure transitions are possibleMet. TLS, mTLS, and OAuth authorization can each be enabled independently and incrementally without a breaking migration. The NoopAuthorizer can be swapped for the OAuth authorizer without a schema or protocol change.
5. Secure defaults are inheritedNot directly applicable. Cadence does not sit on another cloud native security layer, such as a service mesh, that it inherits defaults from. It manages its own TLS and authorization configuration.
6. Exception lists have first-class supportNot met. The NoopAuthorizer can be selected explicitly, but it is also the silent fallback when no authorization: block is configured (factory.go only checks whether the OAuth authorizer is enabled), and Cadence does not log when an operator is running in that mode.
7. Secure defaults protect against pervasive exploitsMet for what is enabled. With TLS and OAuth turned on, Cadence enforces certificate validation, JWT signature verification, and JWT TTL bounds (maxJwtTTL). None of this applies when the features are left off.
8. Security limitations are explainablePartially met. The common/authorization README documents the two authorizer options and their tradeoffs, but there is no consolidated document of known security limitations.

AuthN and AuthZ are under active development. That work is expected to address tenets 2 and 3 by making secure configuration the default path.

Loosening security defaults​

Cadence ships with transport and application-layer security disabled by default, so operators loosen security by leaving these off:

  • Authorization: with no authorization: block in the server config, every RPC is allowed, which is equivalent to the explicit NoopAuthorizer. Enabling it requires configuring oauthAuthorizer with a JWKS URL or a static public key.
  • Transport encryption: with no tls: block, connections between clients, services, and datastores are plaintext. See common/config/tls.go and Mutual TLS.
  • Host verification: when TLS is enabled without setting enableHostVerification, it defaults to false and server certificate hostname checks are skipped. Set enableHostVerification: true for full certificate validation.
  • Client certificates: requireClientAuth defaults to false, so TLS is one-way and only the server is authenticated. Mutual TLS requires requireClientAuth: true.

Cadence has no document written specifically about loosening security. The common/authorization README and the Mutual TLS page describe how to turn each control on, and leaving that configuration out gives the loosened state.