Samze
commented
2 years ago We're interested in helping with this feature and putting together a PR.
However along with the use cases above we also have the following additional usecases:
- I want to create a secret with data from arbitrary k8s resources, e.g. load ip information from a Service.
- I want to load arbitrary k8s resources whose name is dynamic e.g. Load a RabbitmqCluster resource using the name defined in a RMQUser resource that can found in the field
.spec.rabbitmqClusterReference.name - I want to create a secret with a string that is static and pre-defined.
- For simple cases, I want to use jsonpath syntax to define my templated secret
- For advanced cases, I want to use ytt syntax to define my templated secret
So this SecretTemplate would become more flexible to support a wider range of inputs.
Based on the combination of these requirements we have sketched out what a resource could look like. This Resource allows arbitrary input resources and allows either jsonpath or ytt style templating.
---
apiVersion: secretgen.k14s.io/v1alpha1
kind: SecretTemplate
metadata:
name: generated-secret
spec:
# ServiceAccount whose identity is used to `get` inputResources. This would only
# require the RBAC to get a resource and its status. Other RBAC necessary for this
# controller but not associated with the input resources will be supplied a-priori to
# the controller e.g. the RBAC necessary to create and update the templated Secret.
serviceAccountName: my-resource-reader
# An array of resources which have values on their API pertinent to creation of the
# final Secret.
inputResources:
# The name of the key used to refer to this input resource in other jsonpath syntax
# occurrences seen in a) other input resources in this array or b) in the Secret
# .spec.template.
- name: rds
ref:
apiVersion: rds.services.k8s.aws/v1alpha1
kind: DBInstance
# Possibly optional if selector is present.
name: my-rds-instance
# Optional. Possible extension. Allows reading of resources across namespaces.
# May have repercussions due to SecretTemplate creator being able to read arbitrary
# resources across all namespaces, but this is mitigated if we ensure that the
# reading of input resources uses .spec.serviceAccountName’s permissions.
namespace: rds-services
# Optional. Possible extension. Allows resource selection via Labels (or
# fields), will fail if the number of matches != 1.
​​selector:
matchLabels:
type: ha
- name: creds
ref:
apiVersion: v1
kind: Secret
# Possible extension. The name of a input resource could be provided via the value
# of a path on another resource. Allowing acyclic graphs of resource dependencies
# to be expressed. Cyclic references e.g. rds -> creds -> rds would be prevented
# or recognised and causing an error. A suggested way is to require that any
# referenced input resource must precede the current input resource. That way it's
# impossible to create cycles and the logical flow is also more clear.
name: {.rds.masterPassword.name}
namespace: rds-services
# Secret template for the Secret this CR will create. Optional, either template OR ytt must be defined.
template:
# Possible extension. Metadata exposed to allow the templating in of the name of the
# Secret. This would also allow the exposure of label/annotation setting which could
# be useful when specifying Secrets as claimable.
metadata:
name: db-instance-secret
labels:
services-type: aws-rds
# Use jsonpath syntax for referencing values on the input resources, otherwise it is
# static.
stringData:
type: postgresql
port: {.rds.status.endpoint.port}
database: {.rds.spec.dbName}
host: {.rds.status.endpoint.address}
username: {.rds.spec.masterUsername}
# Data would be used to set base64 encoded data.
data:
password: {.creds.data.password}
# Possible extension, allows the templating
# of a Secret using ytt. Optional either template OR ytt must be defined. Would enable more complex use cases such as: dynamic loading
# of keys from another resource (to access in a Secret), defaulting, and assertions.
ytt: |
#@ load("@ytt:data", "data")
# Store the input resource as data values with the key being
# the specified reference name.
#@ rds = data.values.rds
#@ creds = data.values.creds
#@ endpoint = rds.status.endpoint
metadata:
name: db-instance-secret
stringData:
type: postgresql
database: #@ rds.spec.dbName
port: #@ endpoint.port
host: #@ endpoint.address
# Example of defaulting.
username: #@ rds.spec.masterUsername if rds.spec.masterUsername != "" else "admin"
data:
# Example of dynamic key loading.
password: #@ creds.data[rds.masterUserPassword.get("key")]
status:
createdSecret:
name: db-instance-secret
conditions:
# All input resources exist
- lastTransitionTime: 2019-10-22T16:29:24Z
status: True
type: InputResourcesFound
# Templating has succeeded
- lastTransitionTime: 2019-10-22T16:29:24Z
status: True
type: TemplateSucceeded
# The Secret is created with templated values
- lastTransitionTime: 2019-10-22T16:30:24Z
status: True
type: SecretCreated
- lastTransitionTime: 2019-10-22T16:31:24Z
status: True
type: ReadySome thoughts/questions we still have:
- The current jsonpath syntax defined would require using double quotes, we should investigate what syntax is most appropriate here. Tekton uses
$( ), Cartographer uses$( )$. - Should the template implicitly create a secret with the same name much like other carvel tooling, or should we allow it to be user defined or take advantage of GenerateName.
- Should the generated Secret be immutable?
- Should we start with the simple jsonpath templating case and add ytt in the future?
- If all input resources are secrets then
serviceAccountNamecould be optional for simplicity of use? This would need to assume secrets are in the same namespace and if we ever supported x-namespace would need a serviceAccount to be defined.
Future enhancements:
- This resource could support cross namespace loading of resources, we have some usecases for this and access would be controlled by the defined service account, but this is something we could add later as a future enhancement.
- Allowing input resources to be specified by a selector.
If folks are generally happy with the approach we will start working on a PR.
cppforlife
st3v
gmrodgers
Describe the problem/challenge you have Use cases:
Describe the solution you'd like introduce SecretTemplate CR that is able to read one or more secrets and produce another secret.
for example:
TBD:
Anything else you would like to add: [Additional information that will assist in solving the issue.]
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
đź‘Ť "I would like to see this addressed as soon as possible" đź‘Ž "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you would like to work on this issue.