<p>Can someone example to me how CSRF works in the cluster setup?</p>

<p>I have a kubernetes cluster hosting a django website, and I'm having some occasional issues with 403 errors. I have multiple instances of the site load balanced in kubernetes.</p>

<p>How does CSRF work when a POST is sent from 1 instance and handled by another?</p>

<p>Does CSRF site work if the docker images are updated during the time the form is being filled out?</p>

<p>Thanks!</p>

<blockquote>
  <p>Can someone example to me how CSRF works in the cluster setup?</p>
</blockquote>

<p>Exactly the same way it usually ought not to (CSRF is Cross Site Request Forgery, i.e. the attack). To protect against it, you hand out secret tokens to your clients which they must include with subsequent requests. Your backend must validate that the tokens are valid, applicable and were, in fact, issued by a trusted source. There's a few ways to do that bit:</p>

<ul>
<li>You can use MACs for that (in which case you have something pretty close to JSON WebTokens). </li>
<li>You can save your tokens to some trusted store and query that store on subsequent requests.</li>
</ul>

<p>That is pretty much <em>all</em> there is to it.</p>

<p>Since your CSRF protection emerges from the combination of choices you made above, how to make it work in a distributed setup also depends on the specific implementation of the CSRF protection scheme.</p>

<p>Going by the Django docs, the default way to do it uses a 'secret' which is reset every time a user logs in. That means if hitting a different server for two subsequent requests triggers a new log in, all old CSRF tokens are effectively invalidated. So based on that: </p>

<ul>
<li>You need to adapt your Django project to make sure different instances can resume working with the same session, and a re-login is not triggered </li>
<li>All your Django instances need to be able to access the same per log-in secret, so that any one of them can validate a CSRF token issued by any other.</li>
</ul>
