A "holos secret" is a Secret in the secrets namespace of the provisioner
cluster. The put command creates a unique secret from files and
directories listed as arguments, or from a txtar archive provided on
standard input.
Secret data may come from any or all of the following sources:
1. Create a secret from raw data on standard input. --name and --file
must be specified.
2. Create a secret from txtar data on standard input. The secret name
is taken from the --name flag if provided, otherwise is taken from
the first line of the txtar comment.
3. Create a secret from files and directories specified as arguments.
The secret name is the base name of the first argument unless it is
overridden by the --name flag.
This is likely doing too much, really all we care about is this use
case:
holos kv put talosconfig
holos kv get talosconfig | holos txtar
Additionally, I want to get get one command without writing a file:
DATA="$(holos kv get talosconfig --file talosconfig)
The structure of the cli package was getting to be a bit of a mess, time
to clean it up. The structure is much easier to read with each command
in a separate package of related functionality.
This patch makes it easy to fetch one or multiple files from a Secret in
the provisioner cluster to address two primary use cases:
1. Extract files into a temporary directory to provide to other tools.
2. Print one file to stdout.
For example, the secrets.yaml file necessary to reset a talos cluster is
printed to stdout in txtar format with one command:
holos kv get k2-talos
The output has the secret name as the comment, then the value of each key of the data
field is printed as the txtar name and data.
k2-talos-49546d9fd7
-- secrets.yaml --
...
Extracting all of the files in the secret is also simple:
holos kv get k2-talos | holos txtar
8:34PM INF txtar.go:94 writing: secrets.yaml version=0.43.0 header=k2-talos-49546d9fd7 path=secrets.yaml bytes=4841
Extracting one file to stdout is also simple:
holos kv get k2-talos | holos txtar --index=1
This patch adds a command to get a secret and output the keys and values
in txtar format. The goal is to easily save files to temporary
directories for scripts.
```
❯ holos kv get test
test-95m5dh57b9
-- other --
other:j1mGVxKhSD4gAVaaY1IHsDZbXt5vaGEg
-- random --
jeff:3l6QlDmr3aoAyxqDyh7t469n2D23EFHd
```
Without this patch the build command doesn't fill in the cue cluster
name tag, resulting in incorrect output compared to the render command.
With this patch the correct output is generated. Note the `mountPath`
field is correct:
```
❯ holos build ~/workspace/holos-run/holos/docs/examples/platforms/reference/projects/secrets/components/validate
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: default
namespace: default
spec:
provider:
vault:
auth:
kubernetes:
mountPath: k2
role: default
serviceAccountRef:
name: default
path: kv/k8s
server: https://vault.core.ois.run
version: v2
```
Make the log messages clear and readable, for example:
holos render --log-format=json --log-level=debug \
--cluster-name core2 ./docs/examples/platforms/reference/projects/secrets/components/namespaces/ \
2> >(jq -r '"\(.source.file):\(.source.line)\t" + .msg')
The msg field is intended to have an imperative verb, ideally in the
past tense, followed by an actionable noun. Past tense indicates
success where as the "could not foo: "+err error form indicates an
attempt to do something that failed.
config.go:91 finalized config from flags
builder.go:115 cue export --out yaml ./platforms/reference/projects/secrets/components/namespaces
builder.go:85 wrote deploy/clusters/core2/components/prod-secrets-namespaces/prod-secrets-namespaces.gen.yaml
render.go:30 rendered prod-secrets-namespaces
Write the result of the cue evaluation to a cluster specific path for
git ops. The written file works with kubectl apply -f and a future
change will add the flux Kustomization and ArgoCD Application resources
to manage the same api objects using a gitops method.
holos render --cluster-name core2 ./docs/examples/platforms/reference/projects/secrets/components/namespaces/
Content seems more appropriate of a field name, and it makes sense since
we are likely to output other formats than yaml, probably json too. We
need to discriminate on content type, so also add a contentType field.
Semantics are meant to be the same has the http content type header, but
simple.
Without this patch holos --version printed to os.Stderr and used the
default cobra template. This is incompatible with our use of `git tag
v$(./bin/holos --version)`.
