Navigation :

secret.proto

Package: `gloo.solo.io`

Types:

Secret Top-Level Resource
AwsSecret
AzureSecret
TlsSecret
HeaderSecret
AccountCredentialsSecret

Source File: github.com/solo-io/gloo/projects/gloo/api/v1/secret.proto

Secret

Certain features such as the AWS Lambda option require the use of secrets for authentication, configuration of SSL Certificates, and other data that should not be stored in plaintext configuration.

Gloo runs an independent (goroutine) controller to monitor secrets. Secrets are stored in their own secret storage layer. Gloo can monitor secrets stored in the following secret storage services:

Kubernetes Secrets
Hashicorp Vault
Plaintext files (recommended only for testing)
Secrets must adhere to a structure, specified by the option that requires them.

Gloo’s secret backend can be configured in Gloo’s bootstrap options

"aws": .gloo.solo.io.AwsSecret
"azure": .gloo.solo.io.AzureSecret
"tls": .gloo.solo.io.TlsSecret
"oauth": .enterprise.gloo.solo.io.OauthSecret
"apiKey": .enterprise.gloo.solo.io.ApiKey
"header": .gloo.solo.io.HeaderSecret
"credentials": .gloo.solo.io.AccountCredentialsSecret
"extensions": .gloo.solo.io.Extensions
"metadata": .core.solo.io.Metadata

Field	Type	Description
`aws`	.gloo.solo.io.AwsSecret	AWS credentials. Only one of `aws`, `azure`, `tls`, `oauth`, `apiKey`, `header`, `credentials`, or `extensions` can be set.
`azure`	.gloo.solo.io.AzureSecret	Azure credentials. Only one of `azure`, `aws`, `tls`, `oauth`, `apiKey`, `header`, `credentials`, or `extensions` can be set.
`tls`	.gloo.solo.io.TlsSecret	TLS secret specification. Only one of `tls`, `aws`, `azure`, `oauth`, `apiKey`, `header`, `credentials`, or `extensions` can be set.
`oauth`	.enterprise.gloo.solo.io.OauthSecret	Enterprise-only: OAuth secret configuration. Only one of `oauth`, `aws`, `azure`, `tls`, `apiKey`, `header`, `credentials`, or `extensions` can be set.
`apiKey`	.enterprise.gloo.solo.io.ApiKey	Enterprise-only: ApiKey secret configuration. Only one of `apiKey`, `aws`, `azure`, `tls`, `oauth`, `header`, `credentials`, or `extensions` can be set.
`header`	.gloo.solo.io.HeaderSecret	Secrets for use in header payloads (e.g. in the Envoy healthcheck API). Only one of `header`, `aws`, `azure`, `tls`, `oauth`, `apiKey`, `credentials`, or `extensions` can be set.
`credentials`	.gloo.solo.io.AccountCredentialsSecret	Secrets to authenticate as a service user. Only one of `credentials`, `aws`, `azure`, `tls`, `oauth`, `apiKey`, `header`, or `extensions` can be set.
`extensions`	.gloo.solo.io.Extensions	Extensions will be passed along from Listeners, Gateways, VirtualServices, Routes, and Route tables to the underlying Proxy, making them useful for controllers, validation tools, etc. which interact with kubernetes yaml. Some sample use cases: * controllers, deployment pipelines, helm charts, etc. which wish to use extensions as a kind of opaque metadata. * In the future, Gloo may support gRPC-based plugins which communicate with the Gloo translator out-of-process. Opaque Extensions enables development of out-of-process plugins without requiring recompiling & redeploying Gloo’s API. Only one of `extensions`, `aws`, `azure`, `tls`, `oauth`, `apiKey`, `header`, or `credentials` can be set.
`metadata`	.core.solo.io.Metadata	Metadata contains the object metadata for this resource.

AwsSecret

There are two ways of providing AWS secrets:

Method 1: glooctl create secret aws

glooctl create secret aws --name aws-secret-from-glooctl \
    --namespace default \
    --access-key $ACC \
    --secret-key $SEC

will produce a Kubernetes resource similar to this (note the aws field and resource_kind annotation):

apiVersion: v1
data:
  aws: base64EncodedStringForMachineConsumption
kind: Secret
metadata:
  annotations:
    resource_kind: '*v1.Secret'
  creationTimestamp: "2019-08-23T15:10:20Z"
  name: aws-secret-from-glooctl
  namespace: default
  resourceVersion: "592637"
  selfLink: /api/v1/namespaces/default/secrets/secret-e2e
  uid: 1f8c147f-c5b8-11e9-bbf3-42010a8001bc
type: Opaque

Method 2: kubectl apply -f resource-file.yaml
- If using a git-ops flow, or otherwise creating secrets from yaml files, you may prefer to provide AWS credentials using the format below, with aws_access_key_id and aws_secret_access_key fields.
- This circumvents the need for the annotation, which are not supported by some tools such as godaddy/kubernetes-external-secrets

# a sample aws secret resource-file.yaml
apiVersion: v1
data:
  aws_access_key_id: some-id
  aws_secret_access_key: some-secret
kind: Secret
metadata:
  name: aws-secret-abcd
  namespace: default

"accessKey": string
"secretKey": string
"sessionToken": string

Field	Type	Description
`accessKey`	`string`	provided by `glooctl create secret aws`.
`secretKey`	`string`	provided by `glooctl create secret aws`.
`sessionToken`	`string`	provided by `glooctl create secret aws`.

AzureSecret

"apiKeys": map<string, string>

Field	Type	Description
`apiKeys`	`map<string, string>`	provided by `glooctl create secret azure`.

TlsSecret

"certChain": string
"privateKey": string
"rootCa": string

Field	Type	Description
`certChain`	`string`	provided by `glooctl create secret tls`.
`privateKey`	`string`	provided by `glooctl create secret tls`.
`rootCa`	`string`	provided by `glooctl create secret tls`.

HeaderSecret

"headers": map<string, string>

Field	Type	Description
`headers`	`map<string, string>`	A collection of header name to header value mappings, each representing an additional header that could be added to a request. Provided by `glooctl create secret header`.

AccountCredentialsSecret

"username": string
"password": string

Field	Type	Description
`username`	`string`
`password`	`string`