Terraform-provider-kubernetes: Name validation regex is invalid

[alkar]

Terraform Version

Terraform v0.11.10
+ provider.kubernetes v1.3.0

Affected Resource(s)

• kubernetes_cluster_role_binding

Terraform Configuration Files

resource "kubernetes_cluster_role_binding" "example" {
  metadata {
    name = "foo:bar"
  }

  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "ClusterRole"
    name      = "cluster-admin"
  }

  subject {
    kind      = "Group"
    name      = "system:masters"
    api_group = "rbac.authorization.k8s.io"
  }
}

Expected Behavior

I expect the provider to be able to create the resource. The colon is allowed in all RBAC resources as far as I'm aware but I cannot find any relevant documentation.

Actual Behavior

$ terraform plan

Error: kubernetes_cluster_role_binding.example: metadata.0.name a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Steps to Reproduce

1. terraform plan

[alexsomesan]

The error message is correct and represents expected behaviour.
Be aware, this IS the name of the Kubernetes object and is not anything RBAC specific.

Kubernetes does not allow : in object names. Because of that, foo:bar is not a valid object name and that is why you are seeing this error.

The format for object names is documented in the Kubernetes docs here: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names

Even ClusterRoleBinding objects use the same metadata format as all other Kubernetes objects so the same rules apply.

[alkar]

This is definitely permitted in kubernetes. You'll even see that default ClusterRoles and ClusterRoleBindings of various components use this naming scheme,

$ kubectl get clusterrole | grep system:
[ ... ]
system:kube-controller-manager                                         160d
system:kube-dns                                                        160d
system:kube-scheduler                                                  160d
system:kubelet-api-admin                                               160d
system:node                                                            160d
[ ... ]

Here is the original example but using kubectl:

$ cat foobar.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: "foo:bar"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: system:masters
  apiGroup: rbac.authorization.k8s.io
$ kubectl apply -f foobar.yaml
clusterrolebinding.rbac.authorization.k8s.io/foo:bar created
$ kubectl describe clusterrolebinding foo:bar
Name:         foo:bar
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"foo:bar","namespace":""},"roleRef":{"apiG...
Role:
  Kind:  ClusterRole
  Name:  cluster-admin
Subjects:
  Kind   Name            Namespace
  ----   ----            ---------
  Group  system:masters
$

I _believe_ the validation for RBAC happens here which is different (and much simpler) from what you would see for other resources like this.

Thoughts?

[alexsomesan]

@alkar That's a very interesting find. Thanks for pointing it out.

In developing the provider, we use the API types exposed by the kubernetes/client-go libraries our reference, which do explicitly document that ClusterRoleBinding uses the same metav1.ObjectMeta type for it's metadata and points to the naming convention doc I originally linked.

As you've pointed out, this doesn't hold true on the API side. I will get in touch with K8S API SIG and get to the bottom of this.

In the mean time, I'll reopen this issue for tracking the conversation.

[alkar]

@alexsomesan thanks for the quick response.

AFAIK metav1.ObjectMeta does not care about names, the validation happens at a different stage.
The documentation on naming rules is quite vague,

By convention, the names of Kubernetes resources should be up to maximum length of 253 characters and consist of lower case alphanumeric characters, -, and ., but certain resources have more specific restrictions.

But I cannot find any docs on the 'more specific restrictions'.

[alexsomesan]

Yes, that's right. The type itself doesn't validate anything and the Name struct attribute is just a string.
I was only referring to the documentation comment attached to it, which as you noticed is generally describing the format as lower case alphanumeric characters, dashes and dots with potentially additional restrictions, but NOT relaxations. Hence the confusion.
Let me see what the API folks have to say about this validation double standard.

[chrw]

Any news on this issue? I have role bindings in the form of foo:bar which I would like to import into the terraform state. Any chance to see a support for this? Thanks

[Aadryn]

Hi, to add more information to this issue i think that the restriction is enforced only for object that is used to generate a dns entry in Kubernetes, of course namespace, and service. There is also service account that have this limitation.

[thunderball1]

Any news? @alexsomesan

[chrw]

@alexsomesan Can I help in any way with this issue? Just let me know.

[tdmalone]

Related: #324 & #439

[tdmalone]

I will get in touch with K8S API SIG and get to the bottom of this.

@alexsomesan Would love to hear how you went talking with the API SIG on this!

[draggeta]

I have the same issue with a metallb deployment I want to import into terraform. It just doesn't accept ':' in the name of a clusterrole.

[tdmalone]

This issue appears to have been resolved in 1.8.1, released yesterday.

Error: module.eks.kubernetes_cluster_role.metrics_server: metadata.0.name a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is 'a-z0-9?(.a-z0-9?)*')

• Downloading plugin for provider "kubernetes" (1.8.1)...

metadata.0.name: "system-metrics-server" => "system:metrics-server" (forces new resource)

🎉

EDIT: Actually, I spoke too soon - it appears to have been fixed for ClusterRole and Role, but not ClusterRoleBinding and RoleBinding.

[alexsomesan]

https://github.com/terraform-providers/terraform-provider-kubernetes/pull/583 just merged which addresses the remaining issue.

[lucasvianna]

Hi! Do you have any idea when there will be a release with this fix?

[arichiardi]

We detected in kubernetes_namespace it seems, can anybody confirm? I think dots for instance are allowed in a kubernetes namespace but we see this error. Is it worth opening another issue?

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!