search

otterize / network-mapper

Map Kubernetes traffic: in-cluster, to the Internet, and to AWS IAM and export as text, intents, or an image
Apache License 2.0
612 stars 23 forks source link

Service name generation fails due to RFC 1123 subdomain validation schema #247

Open samox73 opened 1 week ago

samox73 commented 1 week ago

The doc (https://docs.otterize.com/reference/service-identities#kubernetes-service-identity-resolution) states that the service name for pods w/o the service-name annotation is generated according to their root owner name. All the . in this name are replaced by _. However when applying the generated ClientIntents, this fails with 

The ClientIntents "some-service_v0_0_1" is invalid: metadata.name: Invalid value: "some-service_v0_0_1": a lowercase RFC 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])?)*')

when this root owner's name is e.g. some-service.v0.0.1, which can be the case for some CRDs. In my case it was the ClusterServiceVersion of the OLM, where it is common to name the CSV according to the version, see https://olm.operatorframework.io/docs/concepts/crds/clusterserviceversion/

My proposal would be to replace all . in the root owner name with - instead to conform to this specification, making the automated generation and application of ClientIntents more resilient, without manual intervention.

orishoshan commented 4 days ago

Hey @samox73, thanks for the issue!

Indeed, you are correct - when generating the metadata.name we should use a different pattern, as you suggest. We'll be making this change soon :)