SID and NS when using AUTH
davidhadas opened this issue · comments
When NoAUTH is used,
- gauard-gate gets SID and NS from env
- guard-service uses SID and NS sent from gauard-gate.
Hence two sides are in sync and it is up to the service yaml env to define the correct sid and ns
When AUTH is used,
- guard-gate gets SID and NS from env
- The guard-service concludes SID and NS from AUTH Token.
Hence the two sides are not necessarily in sync!
Since guard-gate should work even when guard-service is down, we can't rely on guard-service to profile the SID and NS.
Analyze what should we do.
Some options:
- have service confirm gate's sid and ns and send error when not in line
- have gate use KubeAPI to confirm sid and ns (... may need to add more permissions... )
- ??
One option to solve this is to always use TLS and AUTH in production and make it the default for Guard.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
/remove-lifecycle stale
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.