search

jparklab / synology-csi

Container Storage Interface (CSI) for Synology
Apache License 2.0
162 stars 35 forks source link

Authentication (2FA and administrator group) #14

Open dannyyy opened 4 years ago

dannyyy commented 4 years ago

I tried get the CSI driver working. But failed twice. Not sure whether this could be changed or it's given in that way by Synology.

  1. If 2FA is enabled and/or enforced for users than no successful authentication is possible. I'm aware, that the url has an additional attribute of otp to provide this token. But given by its nature, this one will change every minute. Other services like FTP, SMB, ... allow to login without providing this token. Is something similar possible for the API?
    It's arguable which behaviour is the better one - only interactive login on DSM needs the 2FA (all other services not) versus strict enforcement for all services (not the case today)

  2. Is there a way to grant a user just with the privileges for API and iSCSI? I don't like the fact that a fully privileged user is configured. On the one hand, the password is in plain-text and everyone with access to Kubernetes has also full access the Synology NAS. On the other hand the full authentication request (url + username + password) is logged in plain-text. Even the read-access to the secret is prevented, but still accessible through the logs.

I guess these limitations are driven by the feature set offered by Synology and not by the author of the driver. But maybe someone has an idea how to make it more convenient and secure.

jparklab commented 4 years ago

  1. I don't think the driver can support 2FA authentication. The typical way to support such case is issue a persistent access token to a service that does not require 2FA. Let me check if Synology supports service tokens

  2. You can use capabiltities(https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container) to give minimum set of capabilities necessary to mount ISCSI volumes. and roles(https://kubernetes.io/docs/reference/access-authn-authz/rbac/) to give necessary access to the k8s APIs. You are right that username and password are exposed in the log messages and can be a security problem if the driver is used in the multi-user environment. It was done purely to make it easy to debug/troubleshoot. It'd be simple to redact them before logging them to the output.