morph
morph copied to clipboard
Arrange for passing join token to each host
There is one single case where a secret is not the right thing to do:
- Node Join Tokens
Why?
They are usually short lived. For example they expire after 10 minutes or on first use. There is absolutely no reason to persist them anywhere.
They are only used to bootstrap a host on first deployment, so they should be provided only once.
{
"192.168.192.168" = { # hardcoded static ip from iso image
deployment = {
allowJoinToken = true;
};
myconfig.spire-agent = {
joinToken = morph-cli.nodeJoinToken; # overlayed into the configuration from command line argument
};
};
}
See #127
-
morph deploy --joinToken <hash> ...
Please let me know about the design and if a PR would be accepted? Going back to #127, also other bootstrapping approaches are thinkable.
Here is for futher context an identity struct provisioned by a attestation service (spire server) and stocked by a directory service (aedir):
entries:
- spiffe_id: spiffe://playground/nodes/k8s/oso-1
# When generating the join token, use this as predictable node alias
parent_id: spiffe://playground/nodes/k8s/oso-1/tokenalias
dns_names:
# CN of SubjectName matched by SASL/EXTERNAL for LDAP AuthC
- oso-1.k8s.nodes.playground
selectors:
- type: unix # for aedir to work, aehostd identifies as the host it runs on
value: name:aehostd
# - type: unix
# value: path:/nix/store/a0avxqggj4rz791qq9rb4xjm196dj035-aehostd/bin/aehostd
# - type: unix
# value: sha256:3a6eb0790f39ac87c94f3856b2dd2c5d110e6811602261a9a923d3bb23adc8b7
# ---------------------------------------------
# AE-Dir relevant attributes - ignored by spire
# ---------------------------------------------
aedir:
dn: host=oso-1.k8s.nodes.playground,cn=playground-k8s-nodes,cn=playground,ou=ae-dir
aeLocation: cn=BOG-playground,cn=people,ou=ae-dir
aeOwner: uniqueIdentifier=jodo,cn=people,ou=ae-dir
ipHostNumber: 172.0.11.1
aeHwSerialNumber: SERIAL123
aeStockId: STOCKID-675
cn: oso-1.k8s.nodes.playground
host: oso-1.k8s.nodes.playground
# ---------------------------------------------
As one can see, IP address is provided as well as FQDN, and both are fetched by the zone's DNS from LDAP. So bootstrapping the identity first needs to propagate across systems. It most probably will be an asynchronous process triggered by two consecutive runs on morph.