<p>I have an application where each user gets assigned a deployment with 1 pod and a service. Each pod is configured with a persistent volume, allowing user data to persist if the pod needs to be restarted.</p>
<p>Is it possible to allow the user to connect to their persistent volume via ssh? My application rests on this requirement</p>

<p><strong>1.</strong> Your application should be able to handle ssh connection. You have to install and run f.e. openssh-server inside your pod.
Please consider using sidecar concept to perform this task: in your scenario it could be ssh server running along with user/application. pod</p>
<p><strong>2.</strong> You need to expose your application using service type f.e. Loadbalncer - take a look on <a href="https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types" rel="nofollow noreferrer">kubernetes services</a>, then you will be able to access pod from outside the cluster using it and finally SSH to Pod and access PV (using openssh-server).
In your case you will have to use service type LoadBalancer exposed on port 22. Opening port 22 allows you to work with your application.</p>
<p>For example:</p>
<pre class="lang-yaml prettyprint-override"><code>apiVersion: v1
kind: Service
metadata:
  name: your-lb-service
spec:
  selector:
    app: your-app
  ports:
    - protocol: TCP
      port: 22
      targetPort: 22
  type: LoadBalancer
</code></pre>
<p>After service creation execute following commands to verify your LoadbalancerIP:</p>
<pre><code>$ kubectl get svc (#External-IP)
$ kubectl get svc your-lb-service -o jsonpath='{.status.loadBalancer.ingress[0].ip}'
</code></pre>
<p>Also take a look on such <a href="https://www.stackrox.com/post/2020/07/protecting-against-kubernetes-threats-chapter-2-execution/" rel="nofollow noreferrer">issue</a>.
This approach should work but please keep in mind from security point of view it's antipattern.</p>
<p>Malicious code could be executed by gaining access to a running pod, starting a new pod, or exploiting an application vulnerability</p>
<p>This technique under Execution arises when an SSH server is running inside a container, which could allow an attacker who obtains credentials to that container through other means to gain remote access to the container to run malicious code and compromise resources.</p>
<p><strong>Best Practice for Mitigation</strong></p>
<p>In Kubernetes, administrators should limit service exposure and apply Kubernetes Network Policies to restrict network traffic and prevent unintended access to a container that is running an SSH server. Pod configurations should also be hardened to prevent SSH servers from being added at runtime.</p>
