-
Notifications
You must be signed in to change notification settings - Fork 984
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
kubernetes_secret should allow the .
character in the name
#87
Comments
Does wrapping the secret key in quotes help? |
It doesn't. Replacing the |
@rochdev could you paste an example config that isn't working? I'm able to create a secret with resource "kubernetes_secret" "dot-test" {
metadata {
name = "dot.test"
}
data {
".start" = "foo"
"mid.dle" = "foo"
"end." = "foo"
}
}
However, I'm not able to create a secret with a
|
@sl1pm4t Just tried your exact example and cannot even get a plan working. tf plan
Error: kubernetes_secret.dot-test: metadata.0.name a DNS-1123 label must consist of lower case alphanumeric characters or '-', and must start and end with an alphanumeric character (e.g. 'my-name', or '123-abc', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?') When using the CLI it works: kubectl create secret generic "dot.secret" --from-literal=foo=bar
secret "dot.secret" created I am using Terraform I don't know if it would make a difference but the cluster is using Kubernetes |
The issue arises from the metadata validation we apply. We are performing DNS label validation (which only permits alphanum and dashes). However the docs for k8s state:
Meaning the DNS label is too strict for the name attribute. I would open the PR myself but I'm concerned about the effects of changing this general schema (metadata). Furthermore it appears that "certain resources have more specific restrictions", I think we will need to dig through k8s to find the validation rules for this resource. As mentioned in above comments "starting or ending with a UPDATE:
Actually revealed to me kubectl is applying the DNS subdomain validation. Traced to the source in k8s:
|
For those arriving from their preferred search engine, as I did: Importantly, the validation described seems to only allow lowercase characters for secret names. This precludes camelCase. My version: |
The
.
character is allowed by Kubernetes and we use it for many of our existing secrets.The text was updated successfully, but these errors were encountered: