kubernetes pod example for atmoz/sftp

sftp.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: sftp

---

kind: Service
apiVersion: v1
metadata:
  name: sftp
  namespace: sftp
  labels:
    environment: production
spec:
  type: "LoadBalancer"
  ports:
  - name: "ssh"
    port: 22
    targetPort: 22
  selector:
    app: sftp
status:
  loadBalancer: {}

---

kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: sftp
  namespace: sftp
  labels:
    environment:     environment: production
    app: sftp
spec:
  # how many pods and indicate which strategy we want for rolling update
  replicas: 1
  minReadySeconds: 10

  template:

    metadata:
      labels:
        environment: production
        app: sftp
      annotations:
        container.apparmor.security.beta.kubernetes.io/sftp: runtime/default

    spec:
      #secrets and config
      volumes:
      - name: sftp-public-keys
        configMap:
          name: sftp-public-keys
      
      containers:
        #the sftp server itself
        - name: sftp
          image: atmoz/sftp:latest
          imagePullPolicy: Always
          env:
#            - name: PASSWORD
#                valueFrom:
#                  secretKeyRef:
#                    name: sftp-server-sec
#                    key: password
          args: ["myUser::1001:100:incoming,outgoing"] #create users and dirs
          ports:
            - containerPort: 22
          volumeMounts:
            - mountPath: /home/myUser/.ssh/keys
              name: sftp-public-keys
              readOnly: true
          securityContext:
            capabilities:
              add: ["SYS_ADMIN"]
          resources: {}

@riprasad I have just tested it, and the error message for connecting to the sftp server using ssh is a different one.

Also I have never used OpenShift, so this is just my guess, but I have an idea why it doesn't work using the Route.
If a Route really is something similar to a Kubernetes Ingress, then it can't work with SSH connections afaik.
This is because the Ingress system uses the target subdomain to determine which pod to route the connection to.
However a TCP connection does not contain this information.
Only higher level protocol specifications sometimes add this information.
HTTP adds this information, so it can work with Ingress like structures, SSH does not add this information afaik, so it cannot work with Ingress like structures.

Simply put SSH does not specify which domain on that IP it wants to connect to, so there is nothing something Ingress like can do to route the connection to the correct target.

What you have to do instead is reserve some port on the host exclusively for connections to the sftp server.
That is the only way I know of, at least.

That makes sense. Thanks for the explanation @ToMe25

Also, these lines from the documentation pretty much confirms that

An Ingress does not expose arbitrary ports or protocols. Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type=NodePort or Service.Type=LoadBalancer.

@riprasad

Is it possible to get some help with the tweaks you made to get it working on openshift?

@afshinyavari Sure. You'll basically have to create a service account and grant it anyuid SCC to bypass the default security constraints in OpenShift. You can run the below commands as admin to achieve the same: -

$ oc create serviceaccount sftp-sa
$ oc adm policy add-scc-to-user anyuid -z sftp-sa

Use the created service account in your deployment. In addition, you will also need to configure the security context for the container. Here's the snippet:-

spec:
   serviceAccountName: sftp-sa
    containers:       
       securityContext:
            privileged: true

@afshinyavari Also, I found this project which is compatible with OpenShift https://github.com/drakkan/sftpgo

I did not find time to deploy this but please feel free to explore it, since it is openshift compatible out-of-the-box and offers better features too. Let me know if you're able to deploy this successfully, in case you decide to choose this one over atmoz-sftp

sftpgo seems interesting, I will look into using that if I can find the time to do so :)

yea, sftpgo indeed is an interesting project! Do share the manifests if you decide to give it a shot :)

sftpgo is all fine, sadly until you actually need a debug - drakkan/sftpgo#1412