Cannot manage K3S encryption at rest using --kube-apiserver-arg and encryption-provider-config

[IceManGreen]

Hello everyone !

Environmental Info:
K3s Version:
k3s version v1.24.6+k3s1 (a8e0c66)
go version go1.18.6

Node(s) CPU architecture, OS, and Version:
OS AlmaLinux 8.6 (Sky Tiger)
Linux localhost.localdomain 4.18.0-372.26.1.el8_6.x86_64 GNU/Linux

Cluster Configuration:
Cluster on one node

NAME STATUS ROLES AGE VERSION
localhost.localdomain Ready control-plane,master 10m v1.24.6+k3s1

Describe the bug:
Using the option --kube-apiserver-arg=encryption-provider-config=/path/to/encryption_conf.yaml for a custom encryption configuration, the command k3s secrets-encrypt status cannot be used to check the encryption information.

Note that I don't want to use --secrets-encryption option since I want to provide my own encryption configuration

Steps To Reproduce:
Create the following encryption configuration :

#/tmp/enc.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aesgcm:
          keys:
            - name: key1
              secret: DoOdl1a6BtizC2kYDyGJprSQuKcefB9TTcdePGMmb3k=
      - identity: {}

Here I purposely create a configuration with aesgcm to differ from the default algorithm used by k3s for secrets encryption.

Then install K3S with :

curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 666 --kube-apiserver-arg=encryption-provider-config=/path/to/encryption_conf.yaml

To debug the encryption, copy the server token into your dedicated home location :

sudo cp /var/lib/rancher/k3s/server/token $HOME/.rancher/k3s/server/token
sudo chown $USER:$USER $HOME/.rancher/k3s/server/token

Expected behavior:

k3s secrets-encrypt status
Active  Key Type  Name                                                                                                                      
------  --------  ----                                                                                                                       
*      AES-GCM   key1

Actual behavior:

k3s secrets-encrypt status
Encryption Status: Disabled, no configuration file found

Additional context / logs:
Note that if I create a secret, it seems encrypted inside the database with the proper key :

# secret testing /tmp/mysecret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  USERNAME: Ym9iCg== 
  PASSWORD: c2VjcmV0MTIzCg==

$ kubectl apply -f /tmp/mysecret.yaml
secret/mysecret created

$ sudo sqlite3 /var/lib/rancher/k3s/server/db/state.db "SELECT hex(value) FROM kine WHERE name LIKE '%secrets%mysecret'" | xxd -r -p
ƐoW&w"hOqP#Y@m:v1:key1:ԽŖ)      O|)!$Ԕ|g\w܌_s<-wSb%䔯lh@Yrjr0([Xy>ҹ
e|`T"&jHÐD$u#bR7SSBau`5V޳aZb{쪆iGcc9P/9 ;>΍x(
:}-:异T7kb}^TbT#ꩵ@:)+{2D~Ҁv     u5WiA"N|_c#R ޖ
                          pF($P#\8CG
nރ(yAmgWpc8e>Lϖ}ER\WƟD:={iʁCNR>ˑ

Thanks for reading ;)

[brandond]

That is correct, if you provide your own encryption configuration (via --kube-apiserver-arg=encryption-provider-config=/path/to/encryption_conf.yaml) then you cannot use the secrets-encrypt subcommand to manage it. That tool only knows how to manage the config file in the path and format generated by K3s.

[IceManGreen]

Thanks a lot, now I understand it is an expected behavior.
Maybe we could add these information into the documentation, inside Secrets Encryption Docs for example ?

[stale]

This repository uses a bot to automatically label issues which have not had any activity (commit/comment/label) for 180 days. This helps us manage the community issues better. If the issue is still relevant, please add a comment to the issue so the bot can remove the label and we know it is still valid. If it is no longer relevant (or possibly fixed in the latest release), the bot will automatically close the issue in 14 days. Thank you for your contributions.