Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support reverse dns on backups #2525

Closed
n0rad opened this issue Apr 22, 2021 · 6 comments
Closed

Support reverse dns on backups #2525

n0rad opened this issue Apr 22, 2021 · 6 comments
Assignees
Labels
area/volume-backup-restore Volume backup restore kind/question Please use `discussion` to ask questions instead

Comments

@n0rad
Copy link

n0rad commented Apr 22, 2021

Hi,

NFS is not very secured and one mechanism to limit access is by filtering who can connect using reverse DNS resolution.
If the NFS server is using the Kubernetes DNS server, access can be filtered by namespace or service.

# cat /etc/exports
/nfsshare *.longhorn-backend.longhorn-system.svc.cluster.local(rw,fsid=0,sync)

This allows managers to connect to NFS but does not allow backups to do so. *.longhorn-system.svc.cluster.local will not work either because backups pod are not on any service and so have no reverse DNS resolution.

Can you please add backups pod to service so they can be identified as endpoints and have reverse DNS resolution?
If not can you at least add a fixed label to those pods so the service can be declared outside of longhorn?

@n0rad n0rad added the kind/feature Feature request, new feature label Apr 22, 2021
@cclhsu cclhsu added this to New in Community Issue Review via automation Apr 22, 2021
@cclhsu
Copy link

cclhsu commented Apr 27, 2021

Thanks for suggestion! we do plan to add "mananged-by: longhorn" for these pods in future release.

@cclhsu cclhsu moved this from New to Pending user response in Community Issue Review Apr 27, 2021
@PhanLe1010
Copy link
Contributor

PhanLe1010 commented Apr 30, 2021

@n0rad
Just to confirm, #2525 (comment) is what you are looking for, right?

@n0rad
Copy link
Author

n0rad commented Apr 30, 2021

This look like an annotation and not like a label, but if it's a label, this should be enough to allow creation of a service out of it.

@jenting
Copy link
Contributor

jenting commented May 4, 2021

If I remember correctly, the backup happens in the replica manager Pods.
From your use case, we need to add labels to replica manager Pods, is this meet your requirement @n0rad?

Ref to:

@joshimoo
Copy link
Contributor

joshimoo commented May 4, 2021

@n0rad can you see if creation of a service against the label longhorn.io/component=instance-manager works for you?
This will match all instance-manager pods for replicas + engine, since replicas/engines are just processes inside of these pods all of the instances/replicas would be covered.

The recurring jobs just trigger api calls against the longhorn-backend, so as long as the backend + replica/engines have access to the nfs server that should be fine.

@n0rad
Copy link
Author

n0rad commented May 5, 2021

Hum ok, I was not aware that jobs was not those accessing the NFS.

it's working.

By adding a service on longhorn.io/component, replica and engines are enlist.

Managers still need to be able to access the NFS to list available backups so longhorn-backend service also have to be allowed on nfs config.

@n0rad n0rad closed this as completed May 5, 2021
@joshimoo joshimoo moved this from Pending user response to Resolved/Scheduled in Community Issue Review May 6, 2021
@joshimoo joshimoo added the kind/question Please use `discussion` to ask questions instead label May 6, 2021
@joshimoo joshimoo added area/volume-backup-restore Volume backup restore and removed kind/feature Feature request, new feature labels Jul 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/volume-backup-restore Volume backup restore kind/question Please use `discussion` to ask questions instead
Projects
Archived in project
Community Issue Review
Resolved/Scheduled
Development

No branches or pull requests

5 participants