add k3s server + agent example composition #12
Conversation
displague
force-pushed
the
k3s
branch
4 times, most recently
from
03bea74 to
7bca1f5
Compare
Signed-off-by: Marques Johansson <[email protected]>
examples/k3s/composition.yaml
Outdated
| fromFieldPath: spec.metro | ||
| toFieldPath: spec.forProvider.metro | ||
| - type: CombineFromComposite | ||
| toFieldPath: spec.forProvider.userData |
There was a problem hiding this comment.
The userData patch is not applying
There was a problem hiding this comment.
TF user_data is sensitive. The field, as defined in the CRD, is userDataSecretRef.
This will have to be done using writeConnectionSecretToRef / connectionSecretKeys / fromConnectionSecretKey / FromConnectionSecretKey.
There was a problem hiding this comment.
I see that the script requires only the token as variable. Would it make sense to store the whole script in a Secret and only take a reference of that secret in your claim? It will force the claim author to know rest of the content but at least the token won't appear in a resource other than Secret.
Signed-off-by: Marques Johansson <[email protected]>
| toFieldPath: metadata.namespace | ||
| fromFieldPath: spec.secretNamespace | ||
| - type: CombineFromComposite | ||
| toFieldPath: data.userdata |
There was a problem hiding this comment.
| toFieldPath: data.userdata | |
| toFieldPath: stringData.userdata |
data requires the content to be base64 encoded.
| - name: k3s-userdata | ||
| base: | ||
| apiVersion: v1 | ||
| kind: Secret |
There was a problem hiding this comment.
This may work but composition is designed to work with MRs. So I'd suggest using Object from provider-kubernetes. Though that'd force you to have the whole secret YAML as raw template in CombineFromComposite patch since Object accepts raw YAML.
| name: k3s-sv | ||
| spec: | ||
| metro: sv | ||
| k3stoken: t09s3cr37 # This is an example token. |
There was a problem hiding this comment.
This isn't ideal since token is in a resource that is not Secret but only thing I could come up as solution would be to ask for a whole Secret including the rest of the script, which I guess you don't want to do, right?
| runcmd: | ||
| - sudo apt update | ||
| - sudo apt upgrade -y | ||
| - curl -sfL https://get.k3s.io | \ |
There was a problem hiding this comment.
Certificates for the Kubernetes cluster should be sourced from Secrets which could then be managed by cert-manager. This will keep the user in control of secrets rather than having them only available within the servers (and therefor difficult to get access to from a Crossplane composition).
Crossplane compositions would also benefit from this K8s managed certificate for managing helm installs within the created cluster.
|
Curious about the role https://kubernetes.io/docs/concepts/configuration/secret/#ssh-authentication-secrets (SSH Key secrets) could play in this and if k3s tokens could/should be stored as https://kubernetes.io/docs/concepts/configuration/secret/#bootstrap-token-secrets |
Description of your changes
Adds an example composition that creates a new project with a K3s server and agent within it.
Fixes #
I have:
make reviewable testto ensure this PR is ready for review.How has this code been tested