You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An alternative approach would be encouraging the use of enableAuthserviceSelector: {} which results in authservice protection for all pods in a Package namespace.
Blake's original comment:
"Particularly, I want to ensure all Pods have authentication of some type. Postgres or other in-cluster databases can be excluded, but I actually would consider protecting mission app's backend HTTP services by default. This does require the mission app developers to pass the JWT from requests to the frontend to the backend app though.
One attack this protects mission apps from is XSRF between the frontend and backend Pods of the mission app itself. It also protects the backend Pod from other in-cluster attacks, but NetworkPolicies should block other in-cluster requests. Intra-namespace between frontend and backend Pods will always be allowed though and really is vulnerable to some things like XSRF vulnerabilities in the frontend mission app code.
As needed, sure people can configure enableAuthserviceSelector: to only specific labels. But then authservice doesn't actually protect the excluded Pods. I'd rather see us recommend a secure by default configuration. The cluster administer needs to do a careful review of any code that has no authservice-protection and ensure it has sufficient authentication (which may involve a deep code review of a mission app).
We should discuss this though. I think this was the default mission app deployment model in Party Bus. @ntwkninja, did you say you were requiring mission apps to pass a JWT from frontend to backend?"
The text was updated successfully, but these errors were encountered:
rjferguson21
changed the title
Evaluate and implement conservative default authentication protection for mission applications
Evaluate conservative default authentication protection for mission applications
Jun 27, 2024
As a follow on to adding authservice protection support in UDS Core we should evaluate if it makes sense to encourage/enforce default protection by authservice for all pods.
Currently as-implemented users opt-into protecting specific pods by using the
enableAuthserviceSelector
An alternative approach would be encouraging the use of
enableAuthserviceSelector: {}
which results in authservice protection for all pods in a Package namespace.Blake's original comment:
"Particularly, I want to ensure all Pods have authentication of some type. Postgres or other in-cluster databases can be excluded, but I actually would consider protecting mission app's backend HTTP services by default. This does require the mission app developers to pass the JWT from requests to the frontend to the backend app though.
One attack this protects mission apps from is XSRF between the frontend and backend Pods of the mission app itself. It also protects the backend Pod from other in-cluster attacks, but NetworkPolicies should block other in-cluster requests. Intra-namespace between frontend and backend Pods will always be allowed though and really is vulnerable to some things like XSRF vulnerabilities in the frontend mission app code.
As needed, sure people can configure
enableAuthserviceSelector:
to only specific labels. But then authservice doesn't actually protect the excluded Pods. I'd rather see us recommend a secure by default configuration. The cluster administer needs to do a careful review of any code that has no authservice-protection and ensure it has sufficient authentication (which may involve a deep code review of a mission app).We should discuss this though. I think this was the default mission app deployment model in Party Bus. @ntwkninja, did you say you were requiring mission apps to pass a JWT from frontend to backend?"
Originally posted by @bburky in #201 (comment)
The text was updated successfully, but these errors were encountered: