Skip to content
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

EncryptionConfiguration mismatch between documentation and validation of provider aescbc #129610

Open
dimityrmirchev opened this issue Jan 14, 2025 · 3 comments · May be fixed by kubernetes/website#49428
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. sig/auth Categorizes an issue or PR as relevant to SIG Auth. sig/security Categorizes an issue or PR as relevant to SIG Security.

Comments

@dimityrmirchev
Copy link

What happened?

AES-CBC is documented to require 32-byte key in the EncryptionConfiguration

// Each key has to be 32 bytes long for AES-CBC and 16, 24 or 32 bytes for AES-GCM.
and also on the website https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers, however the validation checks for one of 16, 24, 32 sizes
case provider.AESCBC != nil:
allErrs = append(allErrs, validateKeys(provider.AESCBC.Keys, path.Child("aescbc").Child("keys"), aesKeySizes)...)

What did you expect to happen?

I expect that the validation fails when one provides a key of size 16 or 24 bytes or that the documentation gets adapted to the current behaviour.

How can we reproduce it (as minimally and precisely as possible)?

Pass a 24-byte sized key for aescbc provider in an EncryptionConfiguration to the kube-apiserver.

Anything else we need to know?

No response

Kubernetes version

This is valid for the current v1.32.0 version.

Cloud provider

N/A

OS version

# On Linux:
$ cat /etc/os-release
# paste output here
$ uname -a
# paste output here

# On Windows:
C:\> wmic os get Caption, Version, BuildNumber, OSArchitecture
# paste output here

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

@dimityrmirchev dimityrmirchev added the kind/bug Categorizes issue or PR as related to a bug. label Jan 14, 2025
@k8s-ci-robot k8s-ci-robot added needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jan 14, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@dimityrmirchev
Copy link
Author

/sig security

@k8s-ci-robot k8s-ci-robot added sig/security Categorizes an issue or PR as relevant to SIG Security. and removed needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jan 14, 2025
@ialidzhikov
Copy link
Contributor

/sig auth

@k8s-ci-robot k8s-ci-robot added the sig/auth Categorizes an issue or PR as relevant to SIG Auth. label Jan 14, 2025
@github-project-automation github-project-automation bot moved this to Needs Triage in SIG Auth Jan 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. sig/auth Categorizes an issue or PR as relevant to SIG Auth. sig/security Categorizes an issue or PR as relevant to SIG Security.
Projects
Status: Needs Triage
Development

Successfully merging a pull request may close this issue.

3 participants