[Gluster-users] backup-volfile-server on kubernetes

[pankaj kumar]

I am trying to mount glusterfs on a kubernetes pod using a fuse mount.

Kubernetes hardcodes the backup-volfile-servers option that is giving an
error while mounting. I can mount without this option. IS there a way to
make the client happy by setting something on the server?

*Mounting arguments: --description=Kubernetes transient mount for
/var/lib/kubelet/pods/b52eaf11-ff94-11e9-9ced-0a60cc29152c/volumes/kubernetes.io
~glusterfs/glusterfs-fuse --scope -- mount -t
glusterfs -o
auto_unmount,backup-volfile-servers=192.168.103.185,log-file=/var/lib/kubelet/plugins/kubernetes.io/glusterfs/glusterfs-fuse/dc-appserver-689c988d67-7jvnh-glusterfs.log,log-level=ERROR,ro

192.168.103.185:gv0
/var/lib/kubelet/pods/b52eaf11-ff94-11e9-9ced-0a60cc29152c/volumes/kubernetes.io
~glusterfs/glusterfs-fuse*
*Output: Running scope as unit run-18260.scope.*
*WARNING: getfattr not found, certain checks will be skipped..*
*[2019-11-05 06:40:00.282977] E
[glusterfsd.c:825:gf_remember_backup_volfile_server] 0-glusterfs: failed to
set volfile server: File exists*

Thanks a lot in advance,
Pankaj


Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314

Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] untrusted users

[Pankaj Kumar]

Hi Jim

Thanks a lot for your detailed response. Some clarifications:

>> If they have no sudo, they can't mount. Use a centralized authentication
system like freeipa or IdM. Every user should have their own userid that's
unique. No exceptions.
<< Every user has a user id. And they also have sudo access to their units.
Take for eg, AWS. You have a user id you login with but you get root on the
Virtual Machine. We know the username but users have full access to the
local machine.

>> Make mounts for them in fstab. Set ownership and groups on mount points
so each user is restricted to their folder only.
<< If every user has his own mount point, then how does he share anything
with other users?

>> I work in HIPAA rules now, DoD clearance rules earlier. Users are not to
be trusted. Other sysadmins are barely trustable. If users have any access
to adjust the system configuration in any way, take it away. That's your
job not theirs. It's easier to say no 100 times a day than spend 2 weeks in
front of lawyers explaining why untrusted users could create a mess that
involves lawyers and courts, fines and jail time.
<< Very thankful of the warning. We will do our best, get outside
verifications, launch prizes for hacks do everything it takes. We will only
do it when we are certain. We will make sure to limit access at the higher
levels. All online file sharing systems(google drive, Dropbox) do this
thing. That's why we are thinking of writing a layer over Gluster possibly
to achieve this.

 >> If your OS won't support basic system security, choose something that
will. Some Linux distros are not usable in a multiple user environment
(kali is a prime example). I work in an Enterprise environment so I use
RedHat/CEntOS.
<< We are using containers and we intend to give users a choice of base
images. They will be the only user on their linux.

>> Sorry to sound really harsh but this sounds like a nightmare that could
be avoided with a better sysadmin plan. Users are terrible sysadmin.
Programmers are too. Sysadmins are not very good programmers :-(
<< That's what we are trying to do here. We like GlusterFS and I think we
can build something on top of it with only a few tweaks. It supports ACLs
already. If we could write a layer such that we force a container to be
able to mount as the specified user only or not mount at all, we have what
we want already.


Thanks

On Mon, Oct 21, 2019 at 8:00 PM Jim Kinney  wrote:

> Shell access to untrusted users. I would fight that tooth and nail as a
> sysadmin. User that are untrusted get accounts deactivated.
>
> If they have no sudo, they can't mount. Make mounts for them in fstab. Set
> ownership and groups on mount points so each user is restricted to their
> folder only. Use a centralized authentication system like freeipa or IdM.
> Every user should have their own userid that's unique. No exceptions.
>
> I work in HIPAA rules now, DoD clearance rules earlier. Users are not to
> be trusted. Other sysadmins are barely trustable. If users have any access
> to adjust the system configuration in any way, take it away. That's your
> job not theirs. It's easier to say no 100 times a day than spend 2 weeks in
> front of lawyers explaining why untrusted users could create a mess that
> involves lawyers and courts, fines and jail time.
>
> If your OS won't support basic system security, choose something that
> will. Some Linux distros are not usable in a multiple user environment
> (kali is a prime example). I work in an Enterprise environment so I use
> RedHat/CEntOS.
>
> If users can't get things done with out being root, someone has really
> messed up the work flow design.
>
> Sorry to sound really harsh but this sounds like a nightmare that could be
> avoided with a better sysadmin plan. Users are terrible sysadmin.
> Programmers are too. Sysadmins are not very good programmers :-(
>
>
> On October 21, 2019 10:03:46 PM EDT, pankaj kumar
>  wrote:
>>
>> We are attaching a gluster storage to our cluster. We give shell access
>> to our cluster to untrusted users. Each user has a folder in gluster. The
>> problem is that the users could get to mount as any user id and then access
>> the other users files as their own. Is there a way to authenticate a user
>> before a mount?
>>
>> If there is none, can you help us implement a thin authentication layer
>> over mount? Where should we get started.
>>
>> Thanks,
>>
>
> --
> Sent from my Android device with K-9 Mail. All tyopes are thumb related
> and reflect authenticity.
> 
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/118564314
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 P

[Gluster-users] untrusted users

[pankaj kumar]

We are attaching a gluster storage to our cluster. We give shell access to
our cluster to untrusted users. Each user has a folder in gluster. The
problem is that the users could get to mount as any user id and then access
the other users files as their own. Is there a way to authenticate a user
before a mount?

If there is none, can you help us implement a thin authentication layer
over mount? Where should we get started.

Thanks,


Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/118564314

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/118564314

Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

[Gluster-users] Mount Gluster for untrusted users

[Pankaj Kumar]

Hi

Is it possible to not let a user with root access on the network not mount
glisterfs with any other UID than his/her own? Is there a way to
authenticate mount requests?

Thanks,
___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users

[Gluster-users] Access as root user when using root_squash

[pankaj kumar]

I am using a gluster volume share over nfs using root_squash.

I would like most of the servers in the organization use a gluster
share with their specific user id/group id and not able to read other
people's data.

But there have to be some users who can provision the root level
directory for other users and give proper ownership. Is it possible to
do?

Thanks,
___
Gluster-users mailing list
Gluster-users@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-users