oidc.md: Add section for how to select SANs. #1127
Conversation
|
Could you undo the formatting changes? Just makes it a bit easier to review |
This adds some advice for how to choose SANs and some of the considerations. Signed-off-by: Billy Lynch <billy@chainguard.dev>
wlynch
force-pushed
the
fulcio-san-selection
branch
from
e8baeab
to
2caa150
Compare
|
Sorry about that. Done! |
Codecov Report
@@ Coverage Diff @@
## main #1127 +/- ##
==========================================
+ Coverage 55.73% 56.01% +0.28%
==========================================
Files 48 48
Lines 2783 2783
==========================================
+ Hits 1551 1559 +8
+ Misses 1101 1095 -6
+ Partials 131 129 -2 see 2 files with indirect coverage changes Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
| - Is the identifier well-defined? | ||
|
|
||
| All SANs for a provider should be defined and documented. If an issuer has the | ||
| ability to produce different SANs, differences and conditions for these SANs |
There was a problem hiding this comment.
What do you mean by this section? When would an issue produce different SANs?
There was a problem hiding this comment.
Trying to cover bases here 😅
GitLab's issuer serves both users and CI/CD, but will only populate certain claims for each. (they do want to stand up another CI-only issuer, but that's down the road).
I wouldn't be surprised if we see this kind of behavior in a few issuers. I don't think this is necessarily a problem so long as we can clearly distinguish different types of users.
So if we eventually want to support gitlab.com user JWTs for email SANs as well, it's doable so long as both us and GitLab are clear on when a token would be a CI token vs a user token.
Signed-off-by: Billy Lynch <billy@chainguard.dev>
Summary
This adds some advice for how to choose SANs and some of the considerations.
Release Note
NONE
Documentation