-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arrange for passing join token to each host #130
Comments
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. |
There is one single case where a secret is not the right thing to do:
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.
See #127
morph deploy --joinToken <hash> ...
The text was updated successfully, but these errors were encountered: