|
|
|
syntax = "proto3";
|
|
|
|
|
|
|
|
package envoy.admin.v2alpha;
|
|
|
|
|
|
|
|
option java_outer_classname = "ConfigDumpProto";
|
|
|
|
option java_multiple_files = true;
|
|
|
|
option java_package = "io.envoyproxy.envoy.admin.v2alpha";
|
|
|
|
|
|
|
|
import "envoy/api/v2/auth/cert.proto";
|
|
|
|
import "envoy/api/v2/cds.proto";
|
|
|
|
import "envoy/api/v2/lds.proto";
|
|
|
|
import "envoy/api/v2/rds.proto";
|
|
|
|
import "envoy/api/v2/srds.proto";
|
|
|
|
import "envoy/config/bootstrap/v2/bootstrap.proto";
|
|
|
|
|
|
|
|
import "google/protobuf/any.proto";
|
|
|
|
import "google/protobuf/timestamp.proto";
|
|
|
|
|
|
|
|
// [#protodoc-title: ConfigDump]
|
|
|
|
|
|
|
|
// The :ref:`/config_dump <operations_admin_interface_config_dump>` admin endpoint uses this wrapper
|
|
|
|
// message to maintain and serve arbitrary configuration information from any component in Envoy.
|
|
|
|
message ConfigDump {
|
|
|
|
// This list is serialized and dumped in its entirety at the
|
|
|
|
// :ref:`/config_dump <operations_admin_interface_config_dump>` endpoint.
|
|
|
|
//
|
|
|
|
// The following configurations are currently supported and will be dumped in the order given
|
|
|
|
// below:
|
|
|
|
//
|
|
|
|
// * *bootstrap*: :ref:`BootstrapConfigDump <envoy_api_msg_admin.v2alpha.BootstrapConfigDump>`
|
|
|
|
// * *clusters*: :ref:`ClustersConfigDump <envoy_api_msg_admin.v2alpha.ClustersConfigDump>`
|
|
|
|
// * *listeners*: :ref:`ListenersConfigDump <envoy_api_msg_admin.v2alpha.ListenersConfigDump>`
|
|
|
|
// * *routes*: :ref:`RoutesConfigDump <envoy_api_msg_admin.v2alpha.RoutesConfigDump>`
|
|
|
|
repeated google.protobuf.Any configs = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This message describes the bootstrap configuration that Envoy was started with. This includes
|
|
|
|
// any CLI overrides that were merged. Bootstrap configuration information can be used to recreate
|
|
|
|
// the static portions of an Envoy configuration by reusing the output as the bootstrap
|
|
|
|
// configuration for another Envoy.
|
|
|
|
message BootstrapConfigDump {
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
config.bootstrap.v2.Bootstrap bootstrap = 1;
|
|
|
|
|
|
|
|
// The timestamp when the BootstrapConfig was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Envoy's listener manager fills this message with all currently known listeners. Listener
|
|
|
|
// configuration information can be used to recreate an Envoy configuration by populating all
|
|
|
|
// listeners as static listeners or by returning them in a LDS response.
|
|
|
|
// [#next-free-field: 6]
|
|
|
|
message ListenersConfigDump {
|
|
|
|
// Describes a statically loaded listener.
|
|
|
|
message StaticListener {
|
|
|
|
// The listener config.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.Listener listener = 1;
|
|
|
|
|
|
|
|
// The timestamp when the Listener was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Describes a dynamically loaded cluster via the LDS API.
|
|
|
|
message DynamicListener {
|
|
|
|
// This is the per-resource version information. This version is currently taken from the
|
|
|
|
// :ref:`version_info <envoy_api_field_DiscoveryResponse.version_info>` field at the time
|
|
|
|
// that the listener was loaded. In the future, discrete per-listener versions may be supported
|
|
|
|
// by the API.
|
|
|
|
string version_info = 1;
|
|
|
|
|
|
|
|
// The listener config.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.Listener listener = 2;
|
|
|
|
|
|
|
|
// The timestamp when the Listener was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 3;
|
|
|
|
}
|
|
|
|
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
// This is the :ref:`version_info <envoy_api_field_DiscoveryResponse.version_info>` in the
|
|
|
|
// last processed LDS discovery response. If there are only static bootstrap listeners, this field
|
|
|
|
// will be "".
|
|
|
|
string version_info = 1;
|
|
|
|
|
|
|
|
// The statically loaded listener configs.
|
|
|
|
repeated StaticListener static_listeners = 2;
|
|
|
|
|
|
|
|
// The dynamically loaded active listeners. These are listeners that are available to service
|
|
|
|
// data plane traffic.
|
|
|
|
repeated DynamicListener dynamic_active_listeners = 3;
|
|
|
|
|
|
|
|
// The dynamically loaded warming listeners. These are listeners that are currently undergoing
|
|
|
|
// warming in preparation to service data plane traffic. Note that if attempting to recreate an
|
|
|
|
// Envoy configuration from a configuration dump, the warming listeners should generally be
|
|
|
|
// discarded.
|
|
|
|
repeated DynamicListener dynamic_warming_listeners = 4;
|
|
|
|
|
|
|
|
// The dynamically loaded draining listeners. These are listeners that are currently undergoing
|
|
|
|
// draining in preparation to stop servicing data plane traffic. Note that if attempting to
|
|
|
|
// recreate an Envoy configuration from a configuration dump, the draining listeners should
|
|
|
|
// generally be discarded.
|
|
|
|
repeated DynamicListener dynamic_draining_listeners = 5;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Envoy's cluster manager fills this message with all currently known clusters. Cluster
|
|
|
|
// configuration information can be used to recreate an Envoy configuration by populating all
|
|
|
|
// clusters as static clusters or by returning them in a CDS response.
|
|
|
|
message ClustersConfigDump {
|
|
|
|
// Describes a statically loaded cluster.
|
|
|
|
message StaticCluster {
|
|
|
|
// The cluster config.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.Cluster cluster = 1;
|
|
|
|
|
|
|
|
// The timestamp when the Cluster was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Describes a dynamically loaded cluster via the CDS API.
|
|
|
|
message DynamicCluster {
|
|
|
|
// This is the per-resource version information. This version is currently taken from the
|
|
|
|
// :ref:`version_info <envoy_api_field_DiscoveryResponse.version_info>` field at the time
|
|
|
|
// that the cluster was loaded. In the future, discrete per-cluster versions may be supported by
|
|
|
|
// the API.
|
|
|
|
string version_info = 1;
|
|
|
|
|
|
|
|
// The cluster config.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.Cluster cluster = 2;
|
|
|
|
|
|
|
|
// The timestamp when the Cluster was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 3;
|
|
|
|
}
|
|
|
|
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
// This is the :ref:`version_info <envoy_api_field_DiscoveryResponse.version_info>` in the
|
|
|
|
// last processed CDS discovery response. If there are only static bootstrap clusters, this field
|
|
|
|
// will be "".
|
|
|
|
string version_info = 1;
|
|
|
|
|
|
|
|
// The statically loaded cluster configs.
|
|
|
|
repeated StaticCluster static_clusters = 2;
|
|
|
|
|
|
|
|
// The dynamically loaded active clusters. These are clusters that are available to service
|
|
|
|
// data plane traffic.
|
|
|
|
repeated DynamicCluster dynamic_active_clusters = 3;
|
|
|
|
|
|
|
|
// The dynamically loaded warming clusters. These are clusters that are currently undergoing
|
|
|
|
// warming in preparation to service data plane traffic. Note that if attempting to recreate an
|
|
|
|
// Envoy configuration from a configuration dump, the warming clusters should generally be
|
|
|
|
// discarded.
|
|
|
|
repeated DynamicCluster dynamic_warming_clusters = 4;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Envoy's RDS implementation fills this message with all currently loaded routes, as described by
|
|
|
|
// their RouteConfiguration objects. Static routes configured in the bootstrap configuration are
|
|
|
|
// separated from those configured dynamically via RDS. Route configuration information can be used
|
|
|
|
// to recreate an Envoy configuration by populating all routes as static routes or by returning them
|
|
|
|
// in RDS responses.
|
|
|
|
message RoutesConfigDump {
|
|
|
|
message StaticRouteConfig {
|
|
|
|
// The route config.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.RouteConfiguration route_config = 1;
|
|
|
|
|
|
|
|
// The timestamp when the Route was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
message DynamicRouteConfig {
|
|
|
|
// This is the per-resource version information. This version is currently taken from the
|
|
|
|
// :ref:`version_info <envoy_api_field_DiscoveryResponse.version_info>` field at the time that
|
|
|
|
// the route configuration was loaded.
|
|
|
|
string version_info = 1;
|
|
|
|
|
|
|
|
// The route config.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.RouteConfiguration route_config = 2;
|
|
|
|
|
|
|
|
// The timestamp when the Route was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The statically loaded route configs.
|
|
|
|
repeated StaticRouteConfig static_route_configs = 2;
|
|
|
|
|
|
|
|
// The dynamically loaded route configs.
|
|
|
|
repeated DynamicRouteConfig dynamic_route_configs = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Envoy's scoped RDS implementation fills this message with all currently loaded route
|
|
|
|
// configuration scopes (defined via ScopedRouteConfigurationsSet protos). This message lists both
|
|
|
|
// the scopes defined inline with the higher order object (i.e., the HttpConnectionManager) and the
|
|
|
|
// dynamically obtained scopes via the SRDS API.
|
|
|
|
message ScopedRoutesConfigDump {
|
|
|
|
message InlineScopedRouteConfigs {
|
|
|
|
// The name assigned to the scoped route configurations.
|
|
|
|
string name = 1;
|
|
|
|
|
|
|
|
// The scoped route configurations.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
repeated api.v2.ScopedRouteConfiguration scoped_route_configs = 2;
|
|
|
|
|
|
|
|
// The timestamp when the scoped route config set was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
message DynamicScopedRouteConfigs {
|
|
|
|
// The name assigned to the scoped route configurations.
|
|
|
|
string name = 1;
|
|
|
|
|
|
|
|
// This is the per-resource version information. This version is currently taken from the
|
|
|
|
// :ref:`version_info <envoy_api_field_DiscoveryResponse.version_info>` field at the time that
|
|
|
|
// the scoped routes configuration was loaded.
|
|
|
|
string version_info = 2;
|
|
|
|
|
|
|
|
// The scoped route configurations.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
repeated api.v2.ScopedRouteConfiguration scoped_route_configs = 3;
|
|
|
|
|
|
|
|
// The timestamp when the scoped route config set was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 4;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The statically loaded scoped route configs.
|
|
|
|
repeated InlineScopedRouteConfigs inline_scoped_route_configs = 1;
|
|
|
|
|
|
|
|
// The dynamically loaded scoped route configs.
|
|
|
|
repeated DynamicScopedRouteConfigs dynamic_scoped_route_configs = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Envoys SDS implementation fills this message with all secrets fetched dynamically via SDS.
|
|
|
|
message SecretsConfigDump {
|
|
|
|
// DynamicSecret contains secret information fetched via SDS.
|
|
|
|
message DynamicSecret {
|
|
|
|
// The name assigned to the secret.
|
|
|
|
string name = 1;
|
|
|
|
|
|
|
|
// This is the per-resource version information.
|
|
|
|
string version_info = 2;
|
|
|
|
|
|
|
|
// The timestamp when the secret was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 3;
|
|
|
|
|
|
|
|
// The actual secret information.
|
|
|
|
// Security sensitive information is redacted (replaced with "[redacted]") for
|
|
|
|
// private keys and passwords in TLS certificates.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.auth.Secret secret = 4;
|
|
|
|
}
|
|
|
|
|
|
|
|
// StaticSecret specifies statically loaded secret in bootstrap.
|
|
|
|
message StaticSecret {
|
|
|
|
// The name assigned to the secret.
|
|
|
|
string name = 1;
|
|
|
|
|
|
|
|
// The timestamp when the secret was last updated.
|
|
|
|
google.protobuf.Timestamp last_updated = 2;
|
|
|
|
|
|
|
|
// The actual secret information.
|
|
|
|
// Security sensitive information is redacted (replaced with "[redacted]") for
|
|
|
|
// private keys and passwords in TLS certificates.
|
api: protoxform tool and API reformat. (#8309)
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
5 years ago
|
|
|
api.v2.auth.Secret secret = 3;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The statically loaded secrets.
|
|
|
|
repeated StaticSecret static_secrets = 1;
|
|
|
|
|
|
|
|
// The dynamically loaded active secrets. These are secrets that are available to service
|
|
|
|
// clusters or listeners.
|
|
|
|
repeated DynamicSecret dynamic_active_secrets = 2;
|
|
|
|
|
|
|
|
// The dynamically loaded warming secrets. These are secrets that are currently undergoing
|
|
|
|
// warming in preparation to service clusters or listeners.
|
|
|
|
repeated DynamicSecret dynamic_warming_secrets = 3;
|
|
|
|
}
|