forked from Controls/gitea-pages
create access subdirectory
This commit is contained in:
@@ -0,0 +1,15 @@
|
||||
# Bastions
|
||||
This parameter determines whether root logins are only possible from the hosts listed in bastions. Normally the value is taken from the network property of the same name, but this parameter allows overriding the network setting through Hiera.
|
||||
|
||||
### Use bastions
|
||||
Boolean value
|
||||
```
|
||||
aaa::user_bastions: true
|
||||
```
|
||||
|
||||
### Bastion host definitions
|
||||
A list of FQDNs. If use_bastions is true, then root logins are only allowed from the hosts on this list. Note: If the list is empty, login is unrestricted again!
|
||||
```
|
||||
- 'wmgt01.psi.ch'
|
||||
- 'wmgt02.psi.ch'
|
||||
```
|
||||
@@ -0,0 +1,82 @@
|
||||
# Eaccounts (Experiment Account)
|
||||
|
||||
The eaccounts are managed via the Digital User Office (DUO) and used for single experiments at the beamlines.
|
||||
|
||||
Eaccounts reside in the AD in the subtree `OU=users,OU=experiment,OU=it,DC=d,DC=psi,DC=ch` whereas normal accounts are found below `OU=Users,OU=PSI,DC=d,DC=psi,DC=ch`
|
||||
|
||||
Normally eaccounts start with `e` followed by their uid. Some eaccounts where used not only for single experiments, more like GAC accounts, and have thus been renamed:
|
||||
```
|
||||
gac-alvra
|
||||
gac-cristall
|
||||
gac-bernina
|
||||
gac-femto
|
||||
gac-furka
|
||||
gac-maloja
|
||||
gac-slab
|
||||
gac-x01dc
|
||||
gac-x02da
|
||||
gac-x03da
|
||||
gac-x03ma
|
||||
gac-x04db
|
||||
gac-x04sa
|
||||
gac-x05da
|
||||
gac-x05la
|
||||
gac-x06da
|
||||
gac-x06sa
|
||||
gac-x07da
|
||||
gac-x07db
|
||||
gac-x07ma
|
||||
gac-x07mb
|
||||
gac-x09la
|
||||
gac-x09lb
|
||||
gac-x10da
|
||||
gac-x10sa
|
||||
gac-x11ma
|
||||
gac-x12sa
|
||||
gac-x12saop
|
||||
gac-x96sa
|
||||
```
|
||||
|
||||
## Allow Eaccounts
|
||||
|
||||
```
|
||||
aaa::enable_eaccounts: true
|
||||
```
|
||||
|
||||
in Hiera enables eaccounts on a system, default is `false`.
|
||||
|
||||
## Eaccounts and `override_homedir`
|
||||
|
||||
By default the `override_homedir` setting (in Hiera `aaa::override_homedir` ore `base::local_homes`) is ignored for eaccounts.
|
||||
The way this has been solved causes problems with group member lookups with eaccounts enabled.
|
||||
|
||||
Without eaccounts only normal users are found as part of the group (which is correct):
|
||||
```
|
||||
[root@lxdev04 ~]# getent group SARESA
|
||||
SARESA:*:35184:babic_a,ebner,kapeller,...,huppert_m,carulla_m,schoel_m
|
||||
[root@lxdev04 ~]#
|
||||
```
|
||||
|
||||
but with eaccounts enabled only the eaccount members are listed:
|
||||
```
|
||||
[root@lxdev01 ~]# getent group SARESA
|
||||
SARESA:*:35184:e21996,e21997,e21992,...,e17806,e17589,gac-alvra
|
||||
[root@lxdev01 ~]#
|
||||
```
|
||||
|
||||
If for a system this is a problem, and at the same time there is no need for ignoring `override_homedir`, you may enable the eaccounts with
|
||||
|
||||
```
|
||||
aaa::enable_eaccounts: true
|
||||
aaa::enable_eaccounts::ignore_override_homedir: false
|
||||
```
|
||||
|
||||
then you get both type of members:
|
||||
```
|
||||
[root@lxdev07 ~]# getent group SARESA
|
||||
SARESA:*:35184:e21996,...,e17589,ext-kapetanaki_s,...,ext-tyrala_k
|
||||
[root@lxdev07 ~]#
|
||||
```
|
||||
|
||||
There is a [open case](https://access.redhat.com/support/cases/#/case/03912615) at RedHat on how to deal best with this problem.
|
||||
|
||||
@@ -0,0 +1,25 @@
|
||||
# SSH Host Hopping as Root (e.g. between cluster members)
|
||||
|
||||
This is to allow the user `root` on a given machine to log in as `root` onto another machine without using a password or a similar authentication.
|
||||
|
||||
|
||||
The `ssh_server::root_host_trust` list in Hiera configures from which devices root is allowed to connect without special configuration:
|
||||
```
|
||||
ssh_server::root_host_trust:
|
||||
- 'lxdev04.psi.ch'
|
||||
- 'lxdev05.psi.ch'
|
||||
```
|
||||
From security perspective this nodes should have the same or stricter security rules/setup that the target host.
|
||||
|
||||
To actually use host trust the client also needs to configure that while connecting, e.g. in Hiera:
|
||||
|
||||
```
|
||||
ssh_client::try_host_trust: true
|
||||
```
|
||||
|
||||
or spontaneously on the ssh command line with:
|
||||
```
|
||||
ssh -o HostbasedAuthentication=yes ...
|
||||
```
|
||||
or by setting `HostbasedAuthentication yes` in the appropriate place in the ssh configuration (e.g. `~/.ssh/config`).
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
# SSH Server Configuration (sshd)
|
||||
|
||||
|
||||
## Extra Configuration
|
||||
Custom configration to the sshd config file can be added via the `ssh_server::extra_config` key. The config will be added at the end of the `/etc/ssh/sshd_config` file.
|
||||
|
||||
### Force Command
|
||||
|
||||
To configure a force command use:
|
||||
```yaml
|
||||
# add force command
|
||||
ssh_server::extra_config:
|
||||
'Force command for non root users': |
|
||||
Match User *,!root
|
||||
ForceCommand /usr/bin/kpasswd
|
||||
|
||||
```
|
||||
|
||||
## Login Banner
|
||||
A login banner can be configured as follows:
|
||||
|
||||
```yaml
|
||||
# custom banner message on ssh login-prompt
|
||||
|
||||
ssh_server::banner_file: '/etc/sshgw/sshd_message'
|
||||
|
||||
files::files:
|
||||
/etc/sshgw/sshd_message:
|
||||
mode: '0644'
|
||||
owner: 'root'
|
||||
content: |
|
||||
----
|
||||
|
||||
PAUL SCHERRER INSTITUTE
|
||||
________________
|
||||
| __ | ____| |
|
||||
| ____|____ | |
|
||||
|_| |______|__|
|
||||
|
||||
----
|
||||
|
||||
```
|
||||
|
||||
## SFTP Server
|
||||
How to enable/disable and configure a sftp server please refer to [sftp_server](sftp_server).
|
||||
@@ -0,0 +1,11 @@
|
||||
# Custom sudo Rules
|
||||
|
||||
Custom sudo rules can be specify in hiera as follows:
|
||||
|
||||
```yaml
|
||||
aaa::sudo_rules:
|
||||
- 'Defaults:telegraf !requiretty, !syslog'
|
||||
- 'telegraf ALL=(root) NOPASSWD: /usr/lib/telegraf/scripts/nxserver_report.sh'
|
||||
```
|
||||
|
||||
Beside that you might also simply deploy a file to /etc/sudoers.d e.g. via a technique described in [Distribute Files](distribute_files).
|
||||
@@ -0,0 +1,19 @@
|
||||
# User and admin access
|
||||
A list of users and or groups that can access the system. Members of the groups `aaa:admins:` don't need to be members of `aaa::users:` to access a system.
|
||||
|
||||
### Regular access
|
||||
Access for ActiveDirectory (AD) user accounts or groups that are non Experiment accounts. (See e account section for that)
|
||||
```
|
||||
aaa::users:
|
||||
- 'muster_h'
|
||||
- '%unx-project_group'
|
||||
```
|
||||
|
||||
### Sudo access
|
||||
To give root access for AD user accounts or groups via sudo.
|
||||
```
|
||||
aaa::admins:
|
||||
- 'muster_h'
|
||||
- '%unx-project_group'
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user