-
Story
-
Resolution: Won't Do
-
Major
-
None
-
OSSM 2.5.1
-
None
-
False
-
None
-
False
-
Documentation (Ref Guide, User Guide, etc.), Release Notes
-
TODO
-
Enhancement
-
-
We should consider changing the default value for spec.security.identity.type from FirstParty to ThirdParty:
- It follows upstream Istio best practices "Because the properties of the first party token are less secure, Istio will default to using third party tokens."
- FirstParty may have been deprecated in upstream k8s (need to verify), so this could help prevent problems in the future.
- We already document that you must use ThirdParty for systems like ROSA.
- A minor relase like 2.6 seems like a good time to do it, and it will be the default in OSSM 3. Migration from one to the other is not smooth, as it requires all SA tokens to be regenerated for the pods.
- Note: OSSM-6710 created to track the migration doc work, which does not have to hold up the release of 2.6.0.
- Changing the default won't break anything, but it shouldn't be changed for existing control planes. If we have time, we should alter the default for new control planes.
- We should document the process of updating (for existing) from FirstParty to ThirdParty.
- Looks like we've had to deal with this in several other places already, like in the Maistra Test Tool, so perhaps we can clean some of that up.
Note: Ties in with https://docs.openshift.com/container-platform/4.15/authentication/bound-service-account-tokens.html
- is depended on by
-
OSSM-6710 [DOC] 2.6 to 3.0 migration instructions for changing spec.security.identity.type from FirstParty to ThirdParty
-
- Backlog
-