Skip to content

Adds Support for Control Plane TLS#208

Merged
danehans merged 1 commit intoenvoyproxy:mainfrom
danehans:issue_70
Sep 22, 2022
Merged

Adds Support for Control Plane TLS#208
danehans merged 1 commit intoenvoyproxy:mainfrom
danehans:issue_70

Conversation

@danehans
Copy link
Copy Markdown
Contributor

@danehans danehans commented Aug 18, 2022

  • Adds a package for generating control plane auth certs.
  • Adds a const to the EG config pkg to represent the default "envoy-gateway-system" ns.
  • Updates ObjectName() method to get/set the default name of the ProxyInfra type.

fixes: #70

Signed-off-by: danehans daneyonhansen@gmail.com

@danehans danehans requested a review from a team as a code owner August 18, 2022 21:26
@LukeShu
Copy link
Copy Markdown
Contributor

LukeShu commented Aug 23, 2022

To communicate: I haven't been looking at this because it is failing CI.

@danehans danehans changed the title Adds Crypto Pkg for Generating Certs WIP: Adds Crypto Pkg for Generating Certs Aug 25, 2022
@danehans
Copy link
Copy Markdown
Contributor Author

@LukeShu I've been side tracked with other PR. I marked the PR as WIP.

@danehans danehans added the provider/kubernetes Issues related to the Kubernetes provider label Aug 30, 2022
@danehans danehans added this to the 0.2.0-rc2 milestone Aug 30, 2022
@danehans danehans marked this pull request as draft September 13, 2022 18:53
@danehans danehans force-pushed the issue_70 branch 4 times, most recently from 8eeccaf to f2849cd Compare September 20, 2022 14:54
@danehans danehans changed the title WIP: Adds Crypto Pkg for Generating Certs Adds Support for Control Plane TLS Sep 20, 2022
@danehans danehans marked this pull request as ready for review September 20, 2022 15:19
Signed-off-by: danehans <daneyonhansen@gmail.com>
caCertPEM: caCert,
caKeyPEM: caKey,
expiry: expiry,
commonName: "envoy-gateway",
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Common names are deprecated in RFC 2818 (in 2000) in favor of SANs. Major softwares (Golang, Chrome etc) stopped supporting them, so we should just issue certs without common names.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something to consider instead of just not setting the CN (having it be an empty string) is to have it be a human-friendly string; like "Envoy Gateway xDS server" or something.

But yeah, we shouldn't be issuing certs with hostnames in the CN.

@danehans
Copy link
Copy Markdown
Contributor Author

xref #404 will causes this PR to support a TLS secret per managed Envoy deployment.

Copy link
Copy Markdown
Contributor

@LukeShu LukeShu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some nit-picks, but on the whole LGTM.

DefaultNamespace = config.EnvoyGatewayNamespace

// DefaultCertificateLifetime holds the default certificate lifetime (in days).
DefaultCertificateLifetime = 365
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we just have this be DefaultCertificateLifetime = 365*24*time.Hour so it's typed as a time.Duration and we don't need to worry about converting it?

caCertPEM: caCert,
caKeyPEM: caKey,
expiry: expiry,
commonName: "envoy-gateway",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something to consider instead of just not setting the CN (having it be an empty string) is to have it be a human-friendly string; like "Envoy Gateway xDS server" or something.

But yeah, we shouldn't be issuing certs with hostnames in the CN.

Comment on lines +257 to +269
// bigIntHash generates a SubjectKeyId by hashing the modulus of the private
// key. This isn't one of the methods listed in RFC 5280 4.2.1.2, but that also
// notes that other methods are acceptable.
//
// gosec makes a blanket claim that SHA-1 is unacceptable, which is
// false here. The core Go method of generations the SubjectKeyId (see
// https://github.com/golang/go/issues/26676) also uses SHA-1, as recommended
// by RFC 5280.
func bigIntHash(n *big.Int) []byte {
h := sha1.New() // nolint:gosec
h.Write(n.Bytes()) // nolint:errcheck
return h.Sum(nil)
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why have a separate .Write(); hy not skip the .Write() and just return h.Sum(n.Bytes)? Or even skip creating an object at all and

		h := sha1.Sum(n.Bytes())
		return h[:]

(this is what the mentioned code the core crypto/x509 does)

But also, why are we even bothering with this? It's optional in non-CA certificates, and the crypto/x509 code will handle it for us in CA certificates.

Comment on lines +253 to +255
func newSerial(now time.Time) *big.Int {
return big.NewInt(int64(now.Nanosecond()))
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using the time feels weird to me. Perhaps crypto/rand would be better?

	serialNumberLimit := new(big.Int).Lsh(big.NewInt(1), 128)
	serialNumber, err := rand.Int(rand.Reader, serialNumberLimit)

Name: "sds",
MountPath: "/sds",
},
},
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we put them in /mnt or /etc or somewhere? Putting them straight in the root feels weird to me.

Comment on lines +55 to +56
runAsUser: 65534
runAsGroup: 65534
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#200 (comment)

65534 is the magic UID that users outside of your UID namespace show up as. So using it here is questionable. (nss-systemd calls this special user "nobody", but IMO a better name would have been "unknown")

I'm not necessarily asking you to change it, I'm asking you to justify it.

Comment on lines +203 to +204
Type: "RSA PRIVATE KEY",
Bytes: x509.MarshalPKCS1PrivateKey(newKey),
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Getting in to bike-shed territory, but any reason to not use "PRIVATE KEY" and x509.MarshalPKCS8PrivateKey? It'd have fewer things to change if we ever want to switch away from RSA.

@LukeShu
Copy link
Copy Markdown
Contributor

LukeShu commented Sep 22, 2022

If anyone cares, here's some very similar code in Emissary: https://github.com/emissary-ingress/emissary/blob/master/cmd/apiext/ca.go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

provider/kubernetes Issues related to the Kubernetes provider

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Control Plane (xDS Server - Envoy) Auth + Authz

3 participants