This patch enables quickly copying secrets from vault to the provisioner
cluster. For example:
vault kv get -format=json -field data kv/k2/kube-namespace/ceph-csi-rbd/csi-rbd-secret \
| holos create secret --namespace ceph-system csi-rbd-secret --data-stdin --append-hash=false
This patch adds the ceph-csi-rbd helm chart component to the metal
cluster type. The purpose is to enable PersistentVolumeClaims on ois
metal clusters.
Cloud clusters like GKE and EKS are expected to skip rendering the metal
type.
Helm values are handled with CUE. The ceph secret is managed as an
ExternalSecret resource, appended to the rendered output by cue and the
holos cli.
Use:
❯ holos render --cluster-name=k2 ~/workspace/holos-run/holos/docs/examples/platforms/reference/clusters/metal/...
2:45PM INF render.go:40 rendered prod-metal-ceph version=0.47.0 status=ok action=rendered name=prod-metal-ceph
Without this patch scripts incorrectly proceeded without detecting a
secret was not fetched.
holos get secret notfound
8:34AM ERR could not execute version=0.46.3 err="not found: notfound" loc=get.go:66
This patch validates secrets are synced from the provisioner cluster to
a workload cluster. This verifies the eso-creds-refresher job, external
secrets operator, etc...
Refer to
0ae58858f5
for the corresponding commit on the k2 cluster.
This patch prints out the cue file and line numbers when a cue error
contains multiple go errors to unwrap.
For example:
```
❯ holos render --cluster-name=k2 ~/workspace/holos-run/holos/docs/examples/platforms/reference/clusters/workload/...
3:31PM ERR could not execute version=0.46.0 err="could not decode: content: error in call to encoding/yaml.MarshalStream: incomplete value string (and 1 more errors)" loc=builder.go:212
content: error in call to encoding/yaml.MarshalStream: incomplete value string:
/home/jeff/workspace/holos-run/holos/docs/examples/schema.cue:199:11
/home/jeff/workspace/holos-run/holos/docs/examples/cue.mod/gen/external-secrets.io/externalsecret/v1beta1/types_gen.cue:83:14
```
This patch adds basic test data to run integration level tests on the
holos cli command. Tests are structured similar to how the go and cue
maintainers test their own cli tools using the testscripts package.
Fixture data is loaded into a fake kubernetes.Clientset.
The holos root command is executed without using a full sub-process so
the fake kubernetes interface persists across multiple holos commands in
the same test case.
The fake kubernetes interface is reset after the testcase script
concludes and a new one starts.
Take care to read and write absolute paths from the test scripts, the
current working directory of the test runner is not set to $WORK when
executing the custom holos command.
This patch adds a get secret subcommand. With no args, lists holos
secrets. With args, gets each argument.
The use cases are:
1. Extract specified keys to files with --to-file
2. Extract all keys to files with --extract-all
3. Print one key to stdout with --print-key
If no key is specified, the key is implicitly set to the holos secret
name. This behavior should be preserved as part of the api.
This patch adds a holos create secret command that behaves like kubectl
create secret, but for the specific use case of provisioning holos
clusters.
```
❯ holos create secret k2-talos --cluster-name=k2 --from-file=secrets.yaml
4:48PM INF secret.go:104 created: k2-talos-49546d9fd7 version=0.45.0 secret=k2-talos-49546d9fd7 name=k2-talos namespace=secrets
```
Once the corresponding `holos get secret` subcommands are implemented
the kv subcommand may be removed.
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
```
This patch adds the `eso-creds-refresher` CronJob which executes every 8
hours in the holos-system namespace of each workload cluster. The job
creates Secrets with a `token` field representing the id token
credential for a SecretStore to use when synchronizing secrets to and
from the provisioner cluster.
Service accounts in the provisioner cluster are selected with
selector=holos.run/job.name=eso-creds-refresher.
Each selected service account has a token issued with a 12 hour
expiration ttl and is stored in a Secret matching the service account
name in the same namespace in the workload cluster.
The job takes about 25 seconds to run once the image is cached on the
node.
Without this patch the Job on a workload cluster fails with:
```
+ kubectl get serviceaccount -A --selector=holos.run/job.name=eso-creds-refresher --output=json
Error from server (Forbidden): serviceaccounts is forbidden: User
"eso-creds-refresher@holos-run.iam.gserviceaccount.com" cannot list
resource "serviceaccounts" in API group "" at the cluster scope:
requires one of ["container.serviceAccounts.list"] permission(s).
```
This label is intended for the Job to select which service accounts to
issue tokens for. For example:
kubectl get serviceaccount -A --selector=holos.run/job.name=eso-creds-refresher --output=json
Without this patch it is difficult to navigate the structure of the
configuration of the api objects because they're positional elements in
a list.
This patch extracts the configuration of the eso-reader and eso-writer
ServiceAccount, Role, and RoleBinding structs into a definition that
behaves like a function. The individual objects are fields of the
struct instead of positional elements in a list.
This patch adds a ConfigMap and Pod to the eso-creds-refresher
component. The Pod executes the gcloud container, impersonates the
eso-creds-refresher iam service account using workload identity, then
authenticates to the remote provisioner cluster.
This is the foundation for a script to automatically create Secret API
objects in a workload cluster which have a kubernetes service account
token ESO SecretStore resources can use to fetch secrets from the
provisioner cluster.
Once we have that script in place we can turn this Pod into a Job and
replace Vault.
The provisioner cluster is a worker-less autopilot cluster that provides
secrets to other clusters in the platform. The `eso-creds-refresher`
Job in the holos-system namespace of each other cluster refreshes
service account tokens for SecretStores.
This patch adds the IAM structure for the Job implemented by Namespace,
ServiceAccount, Role, and RoleBinding api objects.
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
```
This patch adds a holos component to deploy a SecretStore and
ExternalSecret in the default namespace to validate authentication with
Vault is configured correctly.
The default ksa is used to authenticate to vault.
This patch makes it possible to build all components for a platform with
a single command:
❯ holos render ~/workspace/holos-run/holos/docs/examples/platforms/reference/...
2:51PM INF render.go:39 rendered prod-secrets-eso version=0.42.0 status=ok action=rendered name=prod-secrets-eso
2:51PM INF render.go:39 rendered prod-secrets-namespaces version=0.42.0 status=ok action=rendered name=prod-secrets-namespaces
Note the `reference/...` path base name. Without this patch cue tried
to build an intermediate directory instance.
In helm mode, cue is responsible for producing the values.yaml file.
Holos is responsible for taking the values produced by cue and providing
them to helm to produce rendered kubernetes api objects.
This patch adds intermediate data structures to hold the output from
cue: the helm values, the flux kustomization, and the helm charts to
provide the helm values to.
Holos takes this information and orchestrates running helm template to
render the api objects and write them to the file system for git ops.
Makes the colors look nicer with solarized dark. We probably need to
make solarized an option and have them default to look nice with basic
ansi colors.
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
