Hi,
This is a conversation thats been had in the past, but i want to make sure that everyone has a perspective on this :
what is the default username we should ship the cloud images with ? there seems to be an ever growing not-root voice, which is fine. For CentOS-5/6 I would prefer to still leave it as 'root' for now, however since we dont have CentOS-7 images out there yet, it might be good to get the changes in place now.
options : cloud-user seems to be getting traction as the default username in fedora and some rhel quarters, do we stick with that ?
'centos' is another potentially good option, there is precidence there already.
'somethingelse': what would that something else be ?
- KB
options : cloud-user seems to be getting traction as the default username in fedora and some rhel quarters, do we stick with that ?
'centos' is another potentially good option, there is precidence there already.
If RHEL uses cloud-user then CentOS should follow.
Lucian
On 07/14/2014 03:55 PM, Nux! wrote:
options : cloud-user seems to be getting traction as the default username in fedora and some rhel quarters, do we stick with that ?
'centos' is another potentially good option, there is precidence there already.
If RHEL uses cloud-user then CentOS should follow.
we do quite a bit more than what RHEL does - so I dont really want to limit our options based on what RHEL is doing or isnt doing, I am sure they can make up their own minds :)
- KB
----- Original Message -----
From: "Karanbir Singh" mail-lists@karan.org To: centos-devel@centos.org Sent: Monday, 14 July, 2014 4:16:20 PM Subject: Re: [CentOS-devel] Cloud image default login
On 07/14/2014 03:55 PM, Nux! wrote:
options : cloud-user seems to be getting traction as the default username in fedora and some rhel quarters, do we stick with that ?
'centos' is another potentially good option, there is precidence there already.
If RHEL uses cloud-user then CentOS should follow.
we do quite a bit more than what RHEL does - so I dont really want to limit our options based on what RHEL is doing or isnt doing, I am sure they can make up their own minds :)
Absolutely, but staying consistent in this case might be nice.
On 14 July 2014 16:16, Karanbir Singh mail-lists@karan.org wrote:
On 07/14/2014 03:55 PM, Nux! wrote:
options : cloud-user seems to be getting traction as the default username in fedora and some rhel quarters, do we stick with that ?
'centos' is another potentially good option, there is precidence there already.
If RHEL uses cloud-user then CentOS should follow.
we do quite a bit more than what RHEL does - so I dont really want to limit our options based on what RHEL is doing or isnt doing, I am sure they can make up their own minds :)
As a user, I'd like to be able to take any set of instructions about RHEL and s/RHEL/CentOS/g and have it work (with the exception of all the things people pay RedHat good money for, of course.)
If RHEL is using cloud-user then I would prefer for cloud-user on CentOS to work.
Regards, Dan
On 07/14/2014 04:27 PM, Daniel Ankers wrote:
As a user, I'd like to be able to take any set of instructions about RHEL and s/RHEL/CentOS/g and have it work (with the exception of all the things people pay RedHat good money for, of course.)
in the cloud images they wont, we built our own images ( always have ) and have implemented our own policy.
I guess once rhel images show up for opennebula and in linode, we can start trying to work together a bit more.
my point really is - lets find the best place to be, without needing to just blindly work with what / where rhel is and what they are doing
----- Original Message -----
From: "Karanbir Singh" mail-lists@karan.org To: centos-devel@centos.org Sent: Monday, 14 July, 2014 4:32:18 PM Subject: Re: [CentOS-devel] Cloud image default login
On 07/14/2014 04:27 PM, Daniel Ankers wrote:
As a user, I'd like to be able to take any set of instructions about RHEL and s/RHEL/CentOS/g and have it work (with the exception of all the things people pay RedHat good money for, of course.)
in the cloud images they wont, we built our own images ( always have ) and have implemented our own policy.
I guess once rhel images show up for opennebula and in linode, we can start trying to work together a bit more.
my point really is - lets find the best place to be, without needing to just blindly work with what / where rhel is and what they are doing
Maybe it would be good, for a while, to have both root and cloud-user accounts active? Not sure how this would actually work in reality (ie how the cloud platforms and supporting scripts would deal with it).
In my case, building Cloudstack templates, there is a whole lot of people expecting root to be active, changing this behaviour would mean screwing them over. If CentOS also has this kind of legacy problems - which I expect to be true - then it's something to be thinking about.
If this is not deemed a problem, then it would be nice to have the same sort of consistency between RHEL, CentOS and Fedora in this regard.
Lucian
On 14 Jul 2014, at 16:54, Nux! nux@li.nux.ro wrote:
----- Original Message -----
From: "Karanbir Singh" mail-lists@karan.org To: centos-devel@centos.org Sent: Monday, 14 July, 2014 4:32:18 PM Subject: Re: [CentOS-devel] Cloud image default login
On 07/14/2014 04:27 PM, Daniel Ankers wrote:
As a user, I'd like to be able to take any set of instructions about RHEL and s/RHEL/CentOS/g and have it work (with the exception of all the things people pay RedHat good money for, of course.)
in the cloud images they wont, we built our own images ( always have ) and have implemented our own policy.
I guess once rhel images show up for opennebula and in linode, we can start trying to work together a bit more.
my point really is - lets find the best place to be, without needing to just blindly work with what / where rhel is and what they are doing
Maybe it would be good, for a while, to have both root and cloud-user accounts active? Not sure how this would actually work in reality (ie how the cloud platforms and supporting scripts would deal with it).
In my case, building Cloudstack templates, there is a whole lot of people expecting root to be active, changing this behaviour would mean screwing them over. If CentOS also has this kind of legacy problems - which I expect to be true - then it's something to be thinking about.
If this is not deemed a problem, then it would be nice to have the same sort of consistency between RHEL, CentOS and Fedora in this regard.
The default in cloud is to have a locked root user and use sudo for root operations from a non-privileged user. That’s how Ubuntu does it, and it is how the Fedora image does it. And it is what cloud-init expects to see which is what will link into the public metadata systems on the public clouds.
The default for username should really be ‘centos’ I think. That fits with the other distros who name the user after themselves.
The other thing that needs fixing is ‘cloud-init’ which currently doesn’t detect Enterprise Linux clones using systems properly and makes a hash of a few things. I logged a bug today about it: https://bugs.launchpad.net/cloud-init/+bug/1341508
Bear in mind that cloud-init creates the user as specified in the default cloud-config and locks the root user by default. The kickstart script I knocked together today just creates the root user with a default password, locks the password in the %post (to work around a limitation in anaconda which demands a user if you use —lock) and then leaves the user creation to cloud-init.
That’s certainly what would make the image most useful here.
As further data points, Debian on AWS EC2 uses the 'admin' username, and all Google-supported images on Google Compute Engine (including CentOS) don't have a default account at all, but rather use integrated SSH key management via our metadata server and an open source daemon we install into the guest.
On that note, yes, we're aware of CentOS 7 - congrats to all! - and getting ready to proceed with GCE images of that too after we run it successfully through our test suite.
- Jimmy
On Mon, Jul 14, 2014 at 9:07 AM, Neil Wilson neil@brightbox.co.uk wrote:
On 14 Jul 2014, at 16:54, Nux! nux@li.nux.ro wrote:
----- Original Message -----
From: "Karanbir Singh" mail-lists@karan.org To: centos-devel@centos.org Sent: Monday, 14 July, 2014 4:32:18 PM Subject: Re: [CentOS-devel] Cloud image default login
On 07/14/2014 04:27 PM, Daniel Ankers wrote:
As a user, I'd like to be able to take any set of instructions about RHEL and s/RHEL/CentOS/g and have it work (with the exception of all
the
things people pay RedHat good money for, of course.)
in the cloud images they wont, we built our own images ( always have ) and have implemented our own policy.
I guess once rhel images show up for opennebula and in linode, we can start trying to work together a bit more.
my point really is - lets find the best place to be, without needing to just blindly work with what / where rhel is and what they are doing
Maybe it would be good, for a while, to have both root and cloud-user
accounts active? Not sure how this would actually work in reality (ie how the cloud platforms and supporting scripts would deal with it).
In my case, building Cloudstack templates, there is a whole lot of
people expecting root to be active, changing this behaviour would mean screwing them over.
If CentOS also has this kind of legacy problems - which I expect to be
true - then it's something to be thinking about.
If this is not deemed a problem, then it would be nice to have the same
sort of consistency between RHEL, CentOS and Fedora in this regard.
The default in cloud is to have a locked root user and use sudo for root operations from a non-privileged user. That’s how Ubuntu does it, and it is how the Fedora image does it. And it is what cloud-init expects to see which is what will link into the public metadata systems on the public clouds.
The default for username should really be ‘centos’ I think. That fits with the other distros who name the user after themselves.
The other thing that needs fixing is ‘cloud-init’ which currently doesn’t detect Enterprise Linux clones using systems properly and makes a hash of a few things. I logged a bug today about it: https://bugs.launchpad.net/cloud-init/+bug/1341508
Bear in mind that cloud-init creates the user as specified in the default cloud-config and locks the root user by default. The kickstart script I knocked together today just creates the root user with a default password, locks the password in the %post (to work around a limitation in anaconda which demands a user if you use —lock) and then leaves the user creation to cloud-init.
That’s certainly what would make the image most useful here.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Mon, Jul 14, 2014 at 12:14 PM, Jimmy Kaplowitz jkaplowitz@google.com wrote:
As further data points, Debian on AWS EC2 uses the 'admin' username, and all Google-supported images on Google Compute Engine (including CentOS) don't have a default account at all, but rather use integrated SSH key management via our metadata server and an open source daemon we install into the guest.
But you're not changing root's uid, gid, shell, home directory, or group memberships, right? It's all fun and games until someone touches old tools that have worked consistently for more than a decade with an unexpected discrepancy between UNIX historical settings, and someone's untested "security enhancement". It's the sort of thing that makes people hate security changes.
Blocking direct login access by locking the password and/or blocking SSH root access are all understandable, but should *not* be changed from upstream's defaults without considerable thought. They *will* break procedures that are applied to both systems, especially those that rely on remote SSH key or direct root privileges such as the "knife ssh" command from chef and other SSH based multiple-target tools.
Having to pipe the commands through some kind of sudo adds complexity. Don't get me wrong, I agree that in most cases it can and should be turned off for security reasons. But changing the defaults is going to burn sys-admin's very valuable time. Is it worth the security enhancement to make their lives more difficult?
Hi Nico,
You and I completely agree that unexpected discrepancies often cause problems, break workflows, and make people hate security changes. I've been a Debian developer for over 13 years and a UNIX sysadmin for longer than that. There are many cases where I've made arguments similar to yours inside Google, sometimes even mentioning "knife ssh" itself (yes I've used Chef), and we're more compatible with customers' non-GCE automation because of such arguments.
Despite all of that, adding this account management daemon in GCE makes sense, as do the other carefully chosen integration bits we add. Our account daemon can certainly be disabled without harm (e.g. via systemctl in CentOS 7), doesn't interfere with UNIX ways of working, and doesn't dictate what we do about the root account. It's even careful not to remove keys which were added separately by users, distinguishing carefully via comment lines. All of the software we add is of course free and open source software, typically under the Apache License 2.0, and also typically human-readable Python, shell, systemd unit files, or the like. Some of our software is even packaged in RPMs (built via a hacky internal process); we do plan to reach out to coordinate proper RPM packaging and integration into a suitable CentOS repository.
Regarding your specific concerns about root's passwd data, we don't change that. I forget whether we change CentOS's root SSH login setting; we do change a few other things like disabling password SSH auth and putting in some connection keepalive settings, but it's quite close to stock config. We try to keep our deviations justifiable, and if you think any are not, we'd like to hear about them. :) As one example justification, the SSH connection keepalive is because TCP connections that remain idle too many minutes will get dropped by the GCE firewall.
- Jimmy
We aren't changing root's passwd data.
On Mon, Jul 14, 2014 at 6:44 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Mon, Jul 14, 2014 at 12:14 PM, Jimmy Kaplowitz jkaplowitz@google.com wrote:
As further data points, Debian on AWS EC2 uses the 'admin' username, and
all
Google-supported images on Google Compute Engine (including CentOS) don't have a default account at all, but rather use integrated SSH key
management
via our metadata server and an open source daemon we install into the
guest.
But you're not changing root's uid, gid, shell, home directory, or group memberships, right? It's all fun and games until someone touches old tools that have worked consistently for more than a decade with an unexpected discrepancy between UNIX historical settings, and someone's untested "security enhancement". It's the sort of thing that makes people hate security changes.
Blocking direct login access by locking the password and/or blocking SSH root access are all understandable, but should *not* be changed from upstream's defaults without considerable thought. They *will* break procedures that are applied to both systems, especially those that rely on remote SSH key or direct root privileges such as the "knife ssh" command from chef and other SSH based multiple-target tools.
Having to pipe the commands through some kind of sudo adds complexity. Don't get me wrong, I agree that in most cases it can and should be turned off for security reasons. But changing the defaults is going to burn sys-admin's very valuable time. Is it worth the security enhancement to make their lives more difficult? _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Jul 16, 2014 at 1:03 AM, Jimmy Kaplowitz jkaplowitz@google.com wrote:
Hi Nico,
Regarding your specific concerns about root's passwd data, we don't change that. I forget whether we change CentOS's root SSH login setting; we do change a few other things like disabling password SSH auth and putting in some connection keepalive settings, but it's quite close to stock config. We try to keep our deviations justifiable, and if you think any are not, we'd like to hear about them. :) As one example justification, the SSH connection keepalive is because TCP connections that remain idle too many minutes will get dropped by the GCE firewall.
- Jimmy
We aren't changing root's passwd data.
Good. It sounds like you are doing a thoughtful, cautious job and weighing the consequences before changing defaults.
On Jul 16, 2014 4:32 AM, "Nico Kadel-Garcia" nkadel@gmail.com wrote:
Good. It sounds like you are doing a thoughtful, cautious job and weighing the consequences before changing defaults.
Thanks. That's certainly the goal.
- Jimmy
On 07/14/2014 05:14 PM, Jimmy Kaplowitz wrote:
As further data points, Debian on AWS EC2 uses the 'admin' username, and all Google-supported images on Google Compute Engine (including CentOS) don't have a default account at all, but rather use integrated SSH key management via our metadata server and an open source daemon we install into the guest.
I really like this setup, its possible to implement with cloud-init and some user-metadata injection at instantiation time, but no where as simple as it is with the gce tools.
For now, I'm going with 'centos'@ logins, lets see if we can work through that a bit.
On 15 Jul 2014, at 12:11, Karanbir Singh mail-lists@karan.org wrote:
On 07/14/2014 05:14 PM, Jimmy Kaplowitz wrote:
As further data points, Debian on AWS EC2 uses the 'admin' username, and all Google-supported images on Google Compute Engine (including CentOS) don't have a default account at all, but rather use integrated SSH key management via our metadata server and an open source daemon we install into the guest.
I really like this setup, its possible to implement with cloud-init and some user-metadata injection at instantiation time, but no where as simple as it is with the gce tools.
For now, I'm going with 'centos'@ logins, lets see if we can work through that a bit.
Essentially that should be the setup. Cloudinit should create the default user on startup, not the build process that creates the image.
The only user in the image ought to be root. It is the default config on cloud-init that creates a user and checks to make sure root is locked in the absence of any configuration userdata to the contrary.
Certainly that’s how the Fedora and Ubuntu images work.
On 07/15/2014 12:18 PM, Neil Wilson wrote:
Essentially that should be the setup. Cloudinit should create the default user on startup, not the build process that creates the image.
but the default user is defined in the cloud.cfg which is shipped in the cloud-init package.
my understanding is that unless the metadata supplied to the instance overrides this, then this is the config that gets executed.
On 15 Jul 2014, at 12:27, Karanbir Singh mail-lists@karan.org wrote:
On 07/15/2014 12:18 PM, Neil Wilson wrote:
Essentially that should be the setup. Cloudinit should create the default user on startup, not the build process that creates the image.
but the default user is defined in the cloud.cfg which is shipped in the cloud-init package.
my understanding is that unless the metadata supplied to the instance overrides this, then this is the config that gets executed.
Yes that’s what I mean.
i.e. there is no ‘user’ command in the kickstart file.
cloud-init creates the user dynamically when the VM is created based upon the user data supplied - or the default in the config file.
On 07/15/2014 12:30 PM, Neil Wilson wrote:
cloud-init creates the user dynamically when the VM is created based upon the user data supplied - or the default in the config file.
and this is what I've now changed to be 'centos'
On Tue, Jul 15, 2014 at 12:30:38PM +0100, Neil Wilson wrote:
Yes that’s what I mean. i.e. there is no ‘user’ command in the kickstart file.
Except that currently, anaconda won't let you lock the root password if you don't create a user. (There's a bug report for this somewhere.) In Fedora, we're currently working around it by creating the user and the removing in %post.
On 15 Jul 2014, at 15:41, Matthew Miller mattdm@mattdm.org wrote:
On Tue, Jul 15, 2014 at 12:30:38PM +0100, Neil Wilson wrote:
Yes that’s what I mean. i.e. there is no ‘user’ command in the kickstart file.
Except that currently, anaconda won't let you lock the root password if you don't create a user. (There's a bug report for this somewhere.) In Fedora, we're currently working around it by creating the user and the removing in %post.
I do the opposite and don’t lock the root user, but lock it in %post
As in:
# Install root password - removed and locked in post. rootpw --iscrypted $1$2e74e5$wMj25e4rEb4rJxqm7BAnk0
[snip]
%post
# lock root password passwd -d root passwd -l root
Y
On Tue, Jul 15, 2014 at 10:44 AM, Neil Wilson neil@brightbox.co.uk wrote:
I do the opposite and don’t lock the root user, but lock it in %post
As in:
# Install root password - removed and locked in post. rootpw --iscrypted $1$2e74e5$wMj25e4rEb4rJxqm7BAnk0
%post steps are potentially destabilizing. system-config-kickstart doesn't handle multiple %post steps correctly, it's currently broken anyway, they don't get recorded in anaconda-ks.cfg, and overall they can be very confusing when you access a machine later and say "how was this set up"
Instead use something like this.
# Install locked root password rootpw --iscrypted ***LOCKED***
If you have to add '%post' steps, add this first to preserve a copy for stability.
%post /bin/cp /tmp/ks.cfg /mnt/sysimage/root/ks.cfg
I've no idea why the anaconda kickstart doesn't do this, as well as or instead of that horrid, interpreted, mess of an interpreted and deduced kickstart file that may have no legible resemblance to the original ks.cfg.
On Tue, Jul 15, 2014 at 11:54:29AM -0400, Nico Kadel-Garcia wrote:
I do the opposite and don’t lock the root user, but lock it in %post
# Install locked root password rootpw --iscrypted ***LOCKED***
FWIW, we do this in Fedora as well. (I guess with the philosophy of... using all of the possible solutions at once?)
If you have to add '%post' steps, add this first to preserve a copy for stability. %post /bin/cp /tmp/ks.cfg /mnt/sysimage/root/ks.cfg
For the Fedora images, we're building them in Koji, so you can see the kickstart used directly. http://koji.fedoraproject.org/koji/taskinfo?taskID=7127840
On Tue, 15 Jul 2014, Matthew Miller wrote:
Except that currently, anaconda won't let you lock the root password if you don't create a user. (There's a bug report for this somewhere.) In Fedora, we're currently working around it by creating the user and the removing in %post.
Wouldn't passing a 'locked' hash into anaconda for root attain that?
-- Russ herrold
On 07/14/2014 04:54 PM, Nux! wrote:
Maybe it would be good, for a while, to have both root and cloud-user accounts active? Not sure how this would actually work in reality (ie how the cloud platforms and supporting scripts would deal with it).
for places we end up with cloud-init, that isnt a problem since you can pass in metadata that disables the 'root disable' option and also disable the 'default user' option that creates another user.
I am not sure how that will work for the sudoers entry though, but its worth a look
On 14 Jul 2014, at 17:07, Karanbir Singh mail-lists@karan.org wrote:
On 07/14/2014 04:54 PM, Nux! wrote:
Maybe it would be good, for a while, to have both root and cloud-user accounts active? Not sure how this would actually work in reality (ie how the cloud platforms and supporting scripts would deal with it).
for places we end up with cloud-init, that isnt a problem since you can pass in metadata that disables the 'root disable' option and also disable the 'default user' option that creates another user.
I am not sure how that will work for the sudoers entry though, but its worth a look
Leave the sudoers entry to cloud-init, as they do in Fedora.
This is what I have at present as the system_info entry in the cloud.cfg
system_info: default_user: name: centos lock_passwd: true gecos: CentOS Cloud User groups: [wheel, adm] sudo: ["ALL=(ALL) NOPASSWD:ALL"] shell: /bin/bash distro: rhel paths: cloud_dir: /var/lib/cloud templates_dir: /etc/cloud/templates ssh_svcname: sshd
On 07/14/2014 05:10 PM, Neil Wilson wrote:
Leave the sudoers entry to cloud-init, as they do in Fedora.
This is what I have at present as the system_info entry in the cloud.cfg
system_info: default_user: name: centos lock_passwd: true gecos: CentOS Cloud User groups: [wheel, adm] sudo: ["ALL=(ALL) NOPASSWD:ALL"] shell: /bin/bash distro: rhel paths: cloud_dir: /var/lib/cloud templates_dir: /etc/cloud/templates ssh_svcname: sshd
Interesting, thanks.
I will have a testing image up later today ( been iterating builds and tests at AWS all day today ). For now, lets go with 'centos' as the user, and see if we are breaking lots of stuff.
btw, how does this play with ansible which expects root login to the images ?
On 14 Jul 2014, at 17:13, Karanbir Singh mail-lists@karan.org wrote:
Interesting, thanks.
I will have a testing image up later today ( been iterating builds and tests at AWS all day today ). For now, lets go with 'centos' as the user, and see if we are breaking lots of stuff.
Same here.
How are you doing networking? Fedora strip out the NetworkManager, firewalld and avahi.
On Mon, 14 Jul 2014 17:13:10 +0100 Karanbir Singh mail-lists@karan.org wrote:
Interesting, thanks.
I will have a testing image up later today ( been iterating builds and tests at AWS all day today ). For now, lets go with 'centos' as the user, and see if we are breaking lots of stuff.
FWIW, I find the idea of setting a non priv user on cloud images like this a kind of strange security theater, but it seems everyone is doing it now. ;(
btw, how does this play with ansible which expects root login to the images ?
You can tell ansible to login as a user and use sudo for things. It's just a few more steps in config.
kevin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 14.07.2014 18:34, Kevin Fenzi wrote:
FWIW, I find the idea of setting a non priv user on cloud images like this a kind of strange security theater, but it seems everyone is doing it now. ;(
+1
I'm really not getting this "oh we disable root for security but we enable a user (not called root) to run every command on the system with root privileges and without the need of a password"
this is in no way safer than root access.
also: default usernames can be looked up on the web(e.g. on this ML) so you don't even get some obfuscation by a different username than root.
I really see no reason for this change beside "everyone is doing it!1".
Also cloud-init should work perfectly with root enabled. After all it's a system to change a system at first boot to suite _your_ needs (as a user), so you should be able to pick any username and sudoers config you may want.
kind regards
Sven
On 14 Jul 2014, at 20:18, Sven Kieske svenkieske@gmail.com wrote:
this is in no way safer than root access.
It is because by default you run commands without root access, and you have to specify a requirement to escalate privilege.
That’s the main reason for doing it. By default the safety systems are engaged, and you have to issue an incantation to disengage them.
Importantly it is *safer*, not more *secure*.
Principle of least privilege.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 14.07.2014 21:27, Neil Wilson wrote:
Importantly it is *safer*, not more *secure*.
Okay, I can agree with this, but I'm under the impression most online tutorials mix this up or create false security by subliminal indicating that this would be more secure.
Thanks for your differentiation!
On Tue, Jul 15, 2014 at 11:17 AM, Sven Kieske svenkieske@gmail.com wrote:
On 14.07.2014 21:27, Neil Wilson wrote:
Importantly it is *safer*, not more *secure*.
Okay, I can agree with this, but I'm under the impression most online tutorials mix this up or create false security by subliminal indicating that this would be more secure.
The GCE variant is also mostly more of a safety benefit than a security benefit, but it does have one security benefit: if a user is subsequently removed from the metadata server, or if the key is set to expire (experimentally supported by our agent and used by this nifty feature: https://developers.google.com/compute/docs/ssh-in-browser) and they're removed from the GCE project, it's easier to clean up after people who used to have access but shouldn't any more.
- Jimmy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 16.07.2014 06:25, Jimmy Kaplowitz wrote:
The GCE variant is also mostly more of a safety benefit than a security benefit, but it does have one security benefit: if a user is subsequently removed from the metadata server, or if the key is set to expire (experimentally supported by our agent and used by this nifty feature: https://developers.google.com/compute/docs/ssh-in-browser) and they're removed from the GCE project, it's easier to clean up after people who used to have access but shouldn't any more.
Of course, I was speaking in a more general sense. - From a cloud and multiuser perspective you are totally right.
kind regards
Sven
On Mon, Jul 14, 2014 at 3:18 PM, Sven Kieske svenkieske@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 14.07.2014 18:34, Kevin Fenzi wrote:
FWIW, I find the idea of setting a non priv user on cloud images like this a kind of strange security theater, but it seems everyone is doing it now. ;(
+1
I'm really not getting this "oh we disable root for security but we enable a user (not called root) to run every command on the system with root privileges and without the need of a password"
this is in no way safer than root access.
It can be. SSH key based access, and sudo, can be configured with settings to insist that the commands come from the local host, that they allow only specific commands with specific arguments, or even that they be run through validation tool such as the old 'validate-rsync.sh' script used by various rsync based backup tools.
It ain't perfect, but it profoundly limit the ease of deliberate or accidental destruction.
I've been using Ansible on our CentOS systems, and you can specify the specific user in the playbook or on the CLI as a passed in arg to ansible-playbook:
ansible-playbook -u centos ...
btw, how does this play with ansible which expects root login to the images ?
-- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Should definitely steer away from the root user.
I'd vote for centos. Good differentiator without being obscure.
On Mon, Jul 14, 2014 at 10:55 AM, Nux! nux@li.nux.ro wrote:
options : cloud-user seems to be getting traction as the default username in fedora and some rhel quarters, do we stick with that ?
'centos' is another potentially good option, there is precidence there already.
If RHEL uses cloud-user then CentOS should follow.
Lucian _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-
Daniel Ankers -
Jimmy Kaplowitz -
Karanbir Singh -
Karanbir Singh -
Kevin Fenzi -
Matthew Miller -
Neil Wilson -
Nico Kadel-Garcia -
Nux! -
R P Herrold -
Sena Heydari -
Sven Kieske