Overview
Currently documentation is lacking with respect to deploying the charts for Kubernetes. When using clef, there are some very specific rules that must be followed, otherwise it will result in a configuration that does not work.
In the template values.yaml in the bee chart, the following is featured for clef:
## If enabled it will start clef sidecar container that will auto approve every request
## Clef keys are pregenerated examples and can be replaced with other values
clefSettings:
enabled: false
clefKeys:
bee-0: '{"address":"fd50ede4954655b993ed69238c55219da7e81acf","crypto":{"cipher":"aes-128-ctr","ciphertext":"1c0f603b0dffe53294c7ca02c1a2800d81d855970db0df1a84cc11bc1d6cf364","cipherparams":{"iv":"11c9ac512348d7ccfe5ee59d9c9388d3"},"kdf":"scrypt","kdfparams":{"dklen":32,"n":262144,"p":1,"r":8,"salt":"f6d7a0947da105fa5ef70fa298f65409d12967108c0e6260f847dc2b10455b89"},"mac":"fc6585e300ad3cb21c5f648b16b8a59ca33bcf13c58197176ffee4786628eaeb"},"id":"4911f965-b425-4011-895d-a2008f859859","version":3}'
## Use existing secret (ignores previous clefKeys)
# existingSecret:
## Password for decrypting key (please change it for production deployments)
password: clefbeesecret
## Use existing password (ignores previous keyPassword)
# existingPasswordSecret:Requested Fix
Documentation that is required on the above:
- How to generate multiple clefKeys to be used for deploying many nodes.
- How to achieve (1) when using the same passphrase for all keys.
- The fact that the
bee-0 key nomenclature is assumed and has dire consequences if you install the helm with a release name anything other than 'bee'. You MUST use bee-0, bee-1 etc, and you MUST install the helm chart with a release name bee, ie. helm upgrade --install bee ethersphere/bee --values config.yaml -n namespace where config.yaml are your specific values and namespace is the namespace you wish to install the nodes in.
As a general question to those that are more experienced with clef, is it required to have masterseed.json accessible in the pod? I personally found that I had to do this to get it working. This led to a whole raft of problems when including masterseed.json from a secret and mounting it (specifically, the issues are with the securityContext settings in the Pod. You must ensure that the secret is mounted using octal notation defaultMode: 0400). This then created issues as there is an fsGroup by default. As an fsGroup is specified, Kubernetes will automatically mount the secret with 0440 privileges, and this will cause clef to throw errors and not start.
The only way I got around the aforementioned was by overwriting the securityContext, running everything as root, and deleting the fsGroup declaration in the securityContext. Obviously this has ramifications, but an option to either relax the permission checking by clef, or something else would be an ideal way to fix this?
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent