From 79f4d53079a63d29a29464850da1635864270163 Mon Sep 17 00:00:00 2001 From: Daniel Nephin Date: Thu, 8 Jul 2021 14:52:22 -0400 Subject: [PATCH 1/8] contrib: add first draft of Connect CA developer docs Co-authored-by: Dhia Ayachi --- docs/service-mesh/README.md | 2 +- docs/service-mesh/ca/README.md | 40 ++++++++++++++++++++++ docs/service-mesh/ca/cert-relationship.mmd | 31 +++++++++++++++++ docs/service-mesh/ca/cert-relationship.svg | 1 + 4 files changed, 73 insertions(+), 1 deletion(-) create mode 100644 docs/service-mesh/ca/README.md create mode 100644 docs/service-mesh/ca/cert-relationship.mmd create mode 100644 docs/service-mesh/ca/cert-relationship.svg diff --git a/docs/service-mesh/README.md b/docs/service-mesh/README.md index 7bc16f7f77..470fd28f29 100644 --- a/docs/service-mesh/README.md +++ b/docs/service-mesh/README.md @@ -3,7 +3,7 @@ - call out: envoy/proxy is the data plane, Consul is the control plane - [xDS Server] - a gRPC service that implements [xDS] and handles requests from an [envoy proxy]. - [agent/proxycfg] -- CA Manager - certificate authority +- [Certificate Authority](./ca) for issuing TLS certs for services and client agents - command/connect/envoy - bootstrapping and running envoy - command/connect/proxy - built-in proxy that is dev-only and not supported for production. diff --git a/docs/service-mesh/ca/README.md b/docs/service-mesh/ca/README.md new file mode 100644 index 0000000000..7a12921772 --- /dev/null +++ b/docs/service-mesh/ca/README.md @@ -0,0 +1,40 @@ +# Certificate Authority (Connect CA) + +The Certificate Authority subsystem manages a CA trust chain for issuing certificates to +services and client agents (via auto-encrypt and auto-config). + +## Architecture + +### High level overview + +- we can start with the mind map +- high level explaination of what are the features that are involved in CA (mesh/connect, auto encrypt) +- add all the func that are involved in the CA operations +- relationship between the different certs + + +### CA and Certificate relationship + +This diagram shows the relationship between the CA certificates in Consul primary and +secondary. + +![CA relationship](./cert-relationship.svg) + +[source](./cert-relationship.mmd) + +TODO: describe the relationship + +* what does it mean for the external root CA to be optional + * it always exists , unless the Consul CA provider is used AND it has generated the CA + root. +* relationship between Primary Root CA and Signing CA in the primary + * sometimes its the same thing (Consul, and AWS providers) + * sometimes it is different (Vault provider) +* client agent cert is used by auto-encrypt for Agent HTTP TLS (and client side of RPC + TLS) +* leaf cert service is the cert used by a service in the mesh + +### detailed call flow +- sequence diagram for leader election +- sequence diagram for leaf signing +- sequence diagram for CA cert rotation diff --git a/docs/service-mesh/ca/cert-relationship.mmd b/docs/service-mesh/ca/cert-relationship.mmd new file mode 100644 index 0000000000..85ae848dcb --- /dev/null +++ b/docs/service-mesh/ca/cert-relationship.mmd @@ -0,0 +1,31 @@ +graph TD + + ExternalRootCA["External RootCA (optional)"] + + subgraph "Consul Primary" + PrimaryRootCA["Primary Root CA"] + PrimarySigningCA["Primary Signing CA (conditional)"] + end + + subgraph "Consul Secondary" + SeconarySigningCA["Seconary Signing CA"] + end + + LeafCertAgentPrimary[Leaf Cert Client Agent] + LeafCertServicePrimary[Leaf Cert Service] + + LeafCertAgentSecondary[Leaf Cert Client Agent] + LeafCertServiceSecondary[Leaf Cert Service] + + + ExternalRootCA -.-> PrimaryRootCA + PrimaryRootCA -.-> PrimarySigningCA + + PrimaryRootCA --> SeconarySigningCA + + PrimarySigningCA --> LeafCertAgentPrimary + PrimarySigningCA --> LeafCertServicePrimary + + SeconarySigningCA --> LeafCertAgentSecondary + SeconarySigningCA --> LeafCertServiceSecondary + diff --git a/docs/service-mesh/ca/cert-relationship.svg b/docs/service-mesh/ca/cert-relationship.svg new file mode 100644 index 0000000000..a32f838d19 --- /dev/null +++ b/docs/service-mesh/ca/cert-relationship.svg @@ -0,0 +1 @@ +
Consul Secondary
Consul Primary
Seconary Signing CA
Primary Root CA
Primary Signing CA (conditional)
External RootCA (optional)
Leaf Cert Client Agent
Leaf Cert Service
Leaf Cert Client Agent
Leaf Cert Service
 \ No newline at end of file From 440db2985ad57e135becf8c005c05e6951b8c4ab Mon Sep 17 00:00:00 2001 From: Dhia Ayachi Date: Thu, 8 Jul 2021 16:07:23 -0400 Subject: [PATCH 2/8] add HL diagram on the ca generation sequence --- docs/service-mesh/ca/README.md | 10 ++++-- docs/service-mesh/ca/hl-ca-overview.mmd | 43 +++++++++++++++++++++++++ docs/service-mesh/ca/hl-ca-overview.svg | 1 + 3 files changed, 52 insertions(+), 2 deletions(-) create mode 100644 docs/service-mesh/ca/hl-ca-overview.mmd create mode 100644 docs/service-mesh/ca/hl-ca-overview.svg diff --git a/docs/service-mesh/ca/README.md b/docs/service-mesh/ca/README.md index 7a12921772..a9c7aaa4db 100644 --- a/docs/service-mesh/ca/README.md +++ b/docs/service-mesh/ca/README.md @@ -7,8 +7,14 @@ services and client agents (via auto-encrypt and auto-config). ### High level overview -- we can start with the mind map -- high level explaination of what are the features that are involved in CA (mesh/connect, auto encrypt) +In Consul the leader is responsible for handling of the CA management. +When a leader election happen, and the elected leader do not have any root CA available it will start a process of creating a set of CA certificate. +Those certificates will use to authenticate/encrypt communication between services (service mesh) or between `Consul client agent` (auto-encrypt/auto-config). This process is described in the following diagram: +![CA creation](./hl-ca-overview.svg) + +[source](./hl-ca-overview.mmd) + +- high level explanation of what are the features that are involved in CA (mesh/connect, auto encrypt) - add all the func that are involved in the CA operations - relationship between the different certs diff --git a/docs/service-mesh/ca/hl-ca-overview.mmd b/docs/service-mesh/ca/hl-ca-overview.mmd new file mode 100644 index 0000000000..952f64b98f --- /dev/null +++ b/docs/service-mesh/ca/hl-ca-overview.mmd @@ -0,0 +1,43 @@ +graph TD + subgraph "Primary DC" + leaderP["Leader"] + rootCAI["Root CA "] + rootCA["Root CA "] + Provider["Consul/AWS providers"] + IntermediateProvider["Vault provider"] + intermediateCAP["Intermediate CA "] + leafP["Leaf certificates"] + end + + subgraph "Secondary DC" + leaderS["Leader"] + intermediateCAS["Intermediate CA"] + leafS["Leaf certificates"] + ProviderS["Consul/AWS/Vault providers"] + end + + consulCAS["Consul client Agents"] + servicesS["Mesh services"] + + consulCAP["Consul client Agents"] + servicesP["Mesh services"] + + leaderP -->|use|Provider + leaderP-->|use|IntermediateProvider + Provider--> |fetch/self sign|rootCA + IntermediateProvider --> |fetch/self sign|rootCAI + rootCAI -->|sign| intermediateCAP + intermediateCAP -->|sign| leafP + rootCA -->|sign| leafP + + leaderS -->|use| ProviderS + ProviderS --> |generate csr| intermediateCAS + rootCA -->|sign| intermediateCAS + rootCAI -->|sign| intermediateCAS + intermediateCAS --> |sign| leafS + + leafS -->|auth/encrypt| servicesS + leafS -->|auth/encrypt| consulCAS + leafP -->|auth/encrypt| servicesP + leafP -->|auth/encrypt| consulCAP + diff --git a/docs/service-mesh/ca/hl-ca-overview.svg b/docs/service-mesh/ca/hl-ca-overview.svg new file mode 100644 index 0000000000..76a6166245 --- /dev/null +++ b/docs/service-mesh/ca/hl-ca-overview.svg @@ -0,0 +1 @@ +
Secondary DC
Primary DC
use
use
fetch/self sign
fetch/self sign
sign
sign
sign
use
generate csr
sign
sign
sign
auth/encrypt
auth/encrypt
auth/encrypt
auth/encrypt
Leader
Intermediate CA
Leaf certificates
Consul/AWS/Vault providers
Leader
Root CA
Root CA
Consul/AWS providers
Vault provider
Intermediate CA
Leaf certificates
Consul client Agents
Mesh services
Consul client Agents
Mesh services
 \ No newline at end of file From c5c5d7777cdede8409c4b3aa8aca98964d9604e2 Mon Sep 17 00:00:00 2001 From: Daniel Nephin Date: Thu, 8 Jul 2021 17:07:15 -0400 Subject: [PATCH 3/8] contrib: add description of cert relationship diagram And links to code --- docs/service-mesh/ca/README.md | 40 +++++++++++++++++++++++++--------- 1 file changed, 30 insertions(+), 10 deletions(-) diff --git a/docs/service-mesh/ca/README.md b/docs/service-mesh/ca/README.md index a9c7aaa4db..39f7f6ecf4 100644 --- a/docs/service-mesh/ca/README.md +++ b/docs/service-mesh/ca/README.md @@ -3,6 +3,17 @@ The Certificate Authority subsystem manages a CA trust chain for issuing certificates to services and client agents (via auto-encrypt and auto-config). +The code for the Certificate Authority is in the following packages: +1. most of the core logic is in [agent/consul/leader_connect_ca.go] +2. the providers are in [agent/connect/ca] +3. the RPC interface is in [agent/consul/connect_ca_endpoint.go] + + +[agent/consul/leader_connect_ca.go]: https://github.com/hashicorp/consul/blob/main/agent/consul/leader_connect_ca.go +[agent/connect/ca]: https://github.com/hashicorp/consul/blob/main/agent/connect/ca/ +[agent/consul/connect_ca_endpoint.go]: https://github.com/hashicorp/consul/blob/main/agent/consul/connect_ca_endpoint.go + + ## Architecture ### High level overview @@ -10,6 +21,7 @@ services and client agents (via auto-encrypt and auto-config). In Consul the leader is responsible for handling of the CA management. When a leader election happen, and the elected leader do not have any root CA available it will start a process of creating a set of CA certificate. Those certificates will use to authenticate/encrypt communication between services (service mesh) or between `Consul client agent` (auto-encrypt/auto-config). This process is described in the following diagram: + ![CA creation](./hl-ca-overview.svg) [source](./hl-ca-overview.mmd) @@ -28,17 +40,25 @@ secondary. [source](./cert-relationship.mmd) -TODO: describe the relationship -* what does it mean for the external root CA to be optional - * it always exists , unless the Consul CA provider is used AND it has generated the CA - root. -* relationship between Primary Root CA and Signing CA in the primary - * sometimes its the same thing (Consul, and AWS providers) - * sometimes it is different (Vault provider) -* client agent cert is used by auto-encrypt for Agent HTTP TLS (and client side of RPC - TLS) -* leaf cert service is the cert used by a service in the mesh +In most cases there is an external root CA that provides an intermediate CA that Consul +uses as the Primary Root CA. The only except to this is when the Consul CA Provider is +used without specifying a `RootCert`. In this one case Consul will generate the the Root CA +from the provided primary key, and it will be used in the primary as the top of the chain +of trust. + +In the primary datacenter, the Consul and AWS providers use the Primary Root CA to sign +leaf certificates. The Vault provider uses an intermediate CA to sign leaf certificates. + +Leaf certificates are created for two purposes: +1. the Leaf Cert Service is used by envoy proxies in the mesh to perform mTLS with other + services. +2. the Leaf Cert Client Agent is created by auto-encrypt and auto-config. It is used by + client agents for HTTP API TLS, and for mTLS for RPC requests to servers. + +Any secondary datacenters receive an intermediate certificate, signed by the Primary Root +CA, which is used as the CA certificate to sign leaf certificates in the secondary +datacenter. ### detailed call flow - sequence diagram for leader election From 9a7a06f9f865fecefd87e4b93ecb6087f8ae3e31 Mon Sep 17 00:00:00 2001 From: Daniel Nephin Date: Thu, 8 Jul 2021 17:13:31 -0400 Subject: [PATCH 4/8] contrib: add CA operations --- docs/service-mesh/ca/README.md | 34 ++++++++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/docs/service-mesh/ca/README.md b/docs/service-mesh/ca/README.md index 39f7f6ecf4..719d2881f6 100644 --- a/docs/service-mesh/ca/README.md +++ b/docs/service-mesh/ca/README.md @@ -60,6 +60,40 @@ Any secondary datacenters receive an intermediate certificate, signed by the Pri CA, which is used as the CA certificate to sign leaf certificates in the secondary datacenter. +## Operations + +When trying to learn the CA subsystem it can be helpful to understand the operations that +it can perform. The sections below are the complete set of read, write, and periodic +operations that provide the full behaviour of the CA subsystem. + +### Periodic Operations + +Periodic (or background) opeartions are started automatically by the Consul leader. They run at some interval (often 1 hour). + +- `CAManager.InitializeCA` - attempts to initialize the CA when a leader is ellected. If the synchronous InitializeCA fails, `CAManager.backgroundCAInitialization` runs `InitializeCA` periodically in a goroutine until it succeeds. +- `CAManager.RenewIntermediate` - (called by `CAManager.intermediateCertRenewalWatch`) runs in the primary if the provider uses a separate signing cert (the Vault provider). The operation always runs in the secondary. Renews the signing cert once half its lifetime has passed. +- `CAManager.secondaryCARootWatch` - runs in secondary only. Performs a blocking query to the primary to retrieve any updates to the CA roots and stores them locally. +- `Server.runCARootPruning` - removes non-active and expired roots from state.CARoots + +### Read Operations + +- `RPC.ConnectCA.ConfigurationGet` - returns the CA provider configuration. Only called by user, not by any internal subsystems. +- `RPC.ConnectCA.Roots` - returns all the roots, the trust domain ID, and the ID of the active root. Each "root" also includes the signing key/cert, and any intermediate certs in the chain. It is used (via the cache) by all the connect proxy types. + +### Write Operations + +- `CAManager.UpdateConfiguration` - (via `RPC.ConnectCA.ConfigurationSet`) called by a user when they want to change the provider or provider configuration (ex: rotate root CA). +- `CAManager.Provider.SignIntermediate` - (via `RPC.ConnectCA.SignIntermediate`) called from the secondary DC: + 1. by `CAManager.RenewIntermediate` to sign the new intermediate when the old intermediate is about to expire + 2. by `CAMananger.initializeSecondary` when setting up a new secondary, when the provider is changed in the secondary + by a user action, or when the primary roots changed and the secondary needs to generate a new intermediate for the new + primary roots. +- `CAMananger.SignCertificate` - is used by: + 1. (via `RPC.ConnectCA.Sign`) - called by client agents to sign a leaf cert for a connect proxy (via `agent/cache-types/connect_ca_leaf.go`) + 2. (via in-process call to `RPC.ConnectCA.Sign`) - called by auto-encrypt to sign a leaf cert for a client agent + 3. called by Auto-Config to sign a leaf cert for a client agent + + ### detailed call flow - sequence diagram for leader election - sequence diagram for leaf signing From fa833ac0f814cf6dd55a054aaf648a5d8aa727d5 Mon Sep 17 00:00:00 2001 From: Dhia Ayachi Date: Fri, 9 Jul 2021 10:28:03 -0400 Subject: [PATCH 5/8] fix types and add reference to mesh and auto_config docs --- docs/service-mesh/ca/README.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/docs/service-mesh/ca/README.md b/docs/service-mesh/ca/README.md index 719d2881f6..40861a851f 100644 --- a/docs/service-mesh/ca/README.md +++ b/docs/service-mesh/ca/README.md @@ -18,17 +18,17 @@ The code for the Certificate Authority is in the following packages: ### High level overview -In Consul the leader is responsible for handling of the CA management. +In Consul the leader is responsible for handling the CA management. When a leader election happen, and the elected leader do not have any root CA available it will start a process of creating a set of CA certificate. -Those certificates will use to authenticate/encrypt communication between services (service mesh) or between `Consul client agent` (auto-encrypt/auto-config). This process is described in the following diagram: +Those certificates will be used to authenticate/encrypt communication between services (service mesh) or between `Consul client agent` (auto-encrypt/auto-config). This process is described in the following diagram: ![CA creation](./hl-ca-overview.svg) [source](./hl-ca-overview.mmd) -- high level explanation of what are the features that are involved in CA (mesh/connect, auto encrypt) -- add all the func that are involved in the CA operations -- relationship between the different certs +The features that benefit from Consul CA management are: +- [service Mesh/Connect](https://www.consul.io/docs/connect) +- [auto encrypt](https://www.consul.io/docs/agent/options#auto_encrypt) ### CA and Certificate relationship @@ -43,7 +43,7 @@ secondary. In most cases there is an external root CA that provides an intermediate CA that Consul uses as the Primary Root CA. The only except to this is when the Consul CA Provider is -used without specifying a `RootCert`. In this one case Consul will generate the the Root CA +used without specifying a `RootCert`. In this one case Consul will generate the Root CA from the provided primary key, and it will be used in the primary as the top of the chain of trust. @@ -93,7 +93,6 @@ Periodic (or background) opeartions are started automatically by the Consul lead 2. (via in-process call to `RPC.ConnectCA.Sign`) - called by auto-encrypt to sign a leaf cert for a client agent 3. called by Auto-Config to sign a leaf cert for a client agent - ### detailed call flow - sequence diagram for leader election - sequence diagram for leaf signing From b843a98890264790f5d1b22947c944f58cc9fe58 Mon Sep 17 00:00:00 2001 From: Dhia Ayachi Date: Fri, 9 Jul 2021 10:28:30 -0400 Subject: [PATCH 6/8] Add sequence diagram for leader boot sequence --- docs/service-mesh/ca/README.md | 5 ++++- docs/service-mesh/ca/ca-leader-sequence.mmd | 19 +++++++++++++++++++ docs/service-mesh/ca/ca-leader-sequence.svg | 1 + 3 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 docs/service-mesh/ca/ca-leader-sequence.mmd create mode 100644 docs/service-mesh/ca/ca-leader-sequence.svg diff --git a/docs/service-mesh/ca/README.md b/docs/service-mesh/ca/README.md index 40861a851f..809dae8253 100644 --- a/docs/service-mesh/ca/README.md +++ b/docs/service-mesh/ca/README.md @@ -94,6 +94,9 @@ Periodic (or background) opeartions are started automatically by the Consul lead 3. called by Auto-Config to sign a leaf cert for a client agent ### detailed call flow -- sequence diagram for leader election +![CA Leader Sequence](./ca-leader-sequence.svg) + +[source](./ca-leader-sequence.mmd) + - sequence diagram for leaf signing - sequence diagram for CA cert rotation diff --git a/docs/service-mesh/ca/ca-leader-sequence.mmd b/docs/service-mesh/ca/ca-leader-sequence.mmd new file mode 100644 index 0000000000..f81e66b7ab --- /dev/null +++ b/docs/service-mesh/ca/ca-leader-sequence.mmd @@ -0,0 +1,19 @@ +sequenceDiagram +Participant Provider +Participant PL As Primary Leader +Participant SL As Secondary Leader +Alt Primary don't have a valid CA +PL->>Provider:initializeRootCA (fetch root and sign intermediate) +Provider->>PL:root + intermediate +PL->>PL:RPC ConnectCA.Roots (fetch primary root and store it) +end +SL->>PL: RPC ConnectCA.Roots (fetch primary root and store it) +PL->>SL: Root + intermediate +Alt Secondary needs a new intermediate (check if current intermediate is signed by primary root) +SL->>Provider: Generate CSR +Provider->>SL: CSR +SL->>PL: ConnectCA.SignIntermediate (CSR) +PL->>SL: Intermediate CA (secondary) +SL->>Provider: Set Intermediate (secondary CA) + root (primary CA) +SL->>SL: Store certs in RAFT (primary root + secondary intermediate) +end \ No newline at end of file diff --git a/docs/service-mesh/ca/ca-leader-sequence.svg b/docs/service-mesh/ca/ca-leader-sequence.svg new file mode 100644 index 0000000000..d19b957e44 --- /dev/null +++ b/docs/service-mesh/ca/ca-leader-sequence.svg @@ -0,0 +1 @@ +ProviderPrimary LeaderSecondary LeaderinitializeRootCA (fetch root and sign intermediate)root + intermediateRPC ConnectCA.Roots (fetch primary root and store it)alt[Primary don't have a valid CA]RPC ConnectCA.Roots (fetch primary root and store it)Root + intermediateGenerate CSRCSRConnectCA.SignIntermediate (CSR)Intermediate CA (secondary)Set Intermediate (secondary CA) + root (primary CA)Store certs in RAFT (primary root + secondary intermediate)alt[Secondary needs a new intermediate (check if current intermediate is signed by primary root)]ProviderPrimary LeaderSecondary Leader \ No newline at end of file From 28d4b2316a5a5914c2b4ecfbce62e03a60a6e7e7 Mon Sep 17 00:00:00 2001 From: Dhia Ayachi Date: Fri, 9 Jul 2021 15:24:16 -0400 Subject: [PATCH 7/8] fix typo and add a TODO section for the remaining stuff --- docs/service-mesh/ca/README.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/service-mesh/ca/README.md b/docs/service-mesh/ca/README.md index 809dae8253..2a3d14d637 100644 --- a/docs/service-mesh/ca/README.md +++ b/docs/service-mesh/ca/README.md @@ -1,6 +1,6 @@ # Certificate Authority (Connect CA) -The Certificate Authority subsystem manages a CA trust chain for issuing certificates to +The Certificate Authority Subsystem manages a CA trust chain for issuing certificates to services and client agents (via auto-encrypt and auto-config). The code for the Certificate Authority is in the following packages: @@ -93,10 +93,11 @@ Periodic (or background) opeartions are started automatically by the Consul lead 2. (via in-process call to `RPC.ConnectCA.Sign`) - called by auto-encrypt to sign a leaf cert for a client agent 3. called by Auto-Config to sign a leaf cert for a client agent -### detailed call flow +## detailed call flow ![CA Leader Sequence](./ca-leader-sequence.svg) [source](./ca-leader-sequence.mmd) -- sequence diagram for leaf signing +####TODO: +- sequence diagram for leaf signing - sequence diagram for CA cert rotation From 2e2156a8bb325fcb1a3aea6a3faaa1139278a8a2 Mon Sep 17 00:00:00 2001 From: Daniel Nephin Date: Fri, 16 Jul 2021 16:48:46 -0400 Subject: [PATCH 8/8] contrib: add CA manager states diagram --- docs/service-mesh/ca/README.md | 11 +++++++++++ docs/service-mesh/ca/state-machine.mmd | 23 +++++++++++++++++++++++ docs/service-mesh/ca/state-machine.svg | 1 + 3 files changed, 35 insertions(+) create mode 100644 docs/service-mesh/ca/state-machine.mmd create mode 100644 docs/service-mesh/ca/state-machine.svg diff --git a/docs/service-mesh/ca/README.md b/docs/service-mesh/ca/README.md index 2a3d14d637..cd63244ee2 100644 --- a/docs/service-mesh/ca/README.md +++ b/docs/service-mesh/ca/README.md @@ -101,3 +101,14 @@ Periodic (or background) opeartions are started automatically by the Consul lead ####TODO: - sequence diagram for leaf signing - sequence diagram for CA cert rotation + +## CAManager states + +This section is a work in progress + +TODO: style the diagram to match the others, and add some narative text to describe the +diagram. + +![CA Mananger states](./state-machine.svg) + + diff --git a/docs/service-mesh/ca/state-machine.mmd b/docs/service-mesh/ca/state-machine.mmd new file mode 100644 index 0000000000..214e311679 --- /dev/null +++ b/docs/service-mesh/ca/state-machine.mmd @@ -0,0 +1,23 @@ +stateDiagram-v2 + + [*] --> Uninitialized + Uninitialized --> Initializing : InitializeCA + Uninitialized --> Reconfig : UpdateConfiguration + Reconfig --> Uninitialized : return + + # Initialized can transition to any state + Initialized --> Renew : RenewIntermediate + Initialized --> Uninitialized : Stop + Initialized --> Reconfig : UpdateConfiguration + Initialized --> Initializing : INVALID + + # Initialized is set using validate=false + Uninitialized --> Initialized : INVALID + Reconfig --> Initialized : return + Initializing --> Initialized : InitializeCA complete + Renew --> Initialized : return + + # Uninitialized is set using validate=false + Renew --> Uninitialized : Stop + Reconfig --> Uninitialized : Stop + Initializing --> Uninitialized : Stop diff --git a/docs/service-mesh/ca/state-machine.svg b/docs/service-mesh/ca/state-machine.svg new file mode 100644 index 0000000000..f63e880e08 --- /dev/null +++ b/docs/service-mesh/ca/state-machine.svg @@ -0,0 +1 @@ +
InitializeCA
UpdateConfiguration
return
RenewIntermediate
Stop
UpdateConfiguration
INVALID
INVALID
return
InitializeCA complete
return
Stop
Stop
Stop
Uninitialized
Initializing
Reconfig
Initialized
Renew
 \ No newline at end of file