-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Encode Join Attributes in Bot Certificates #49426
base: master
Are you sure you want to change the base?
Encode Join Attributes in Bot Certificates #49426
Conversation
subject.ExtraNames = append(subject.ExtraNames, | ||
pkix.AttributeTypeAndValue{ | ||
Type: JoinAttributesASN1ExtensionOID, | ||
Value: string(encoded), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can/Should we store this as bytes instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the internal encoding implementation is identical (https://github.com/golang/go/blob/master/src/encoding/asn1/marshal.go#L41-L63) but I believe the values are explicitly typed. That doesn't matter much for us since we'll support whichever datatype we use, but I think tools (openssl, etc) can decide to render plaintext or hex depending on type. That is to say, I think strings are probably better due to the type that will be embedded alongside the value itself.
Technically I think ASN.1 has some native struct encoding we could use, and the go encoder supports it via field tags. That might be technically be "more" "correct" but probably adds too much complexity to be worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah - I have a feeling that encoding as a string may just be the best bet. I think my biggest fear here is overly inflating certificate sizes - I'm yet to really determine the point at which it would become problematic. If testing does indicate this, then maybe we'll need to switch to encoding as binary rather than protojson.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After looking into this, it looks like storing Proto bytes instead actually causes some issues in the Subject DN due to the way Go's implementation of TLS handles parsing X509 certs. So we'll have to stick with string for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this is rendering nicely with openssl x509
, I see: 1.3.9999.2.21={"meta":{"join_method":"token"}}
d51e36a
to
bbb99df
Compare
Since this PR has sat around for a hot second, I'll manually retest this before merging. |
1c7805e
to
58b98e4
Compare
2d8677b
to
b8c5014
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, and join attributes are showing up nicely in certs for me.
subject.ExtraNames = append(subject.ExtraNames, | ||
pkix.AttributeTypeAndValue{ | ||
Type: JoinAttributesASN1ExtensionOID, | ||
Value: string(encoded), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this is rendering nicely with openssl x509
, I see: 1.3.9999.2.21={"meta":{"join_method":"token"}}
As per RFD191: #49133
Closes #49571
Depends on #50680
This PR encodes attributes produced by the join process into the certificates issued to Bots, so that these attributes can be used in authorization and templating decisions made when issuing Workload Identities.
In the v16/v17 backports, a disabled-by-default environment variable flag will be added. In a later release, we may enable this by default.