| |
@@ -6,8 +6,8 @@
|
| |
|
| |
All that is possible at various levels :
|
| |
|
| |
- * Application level : granted needed credentials (usually authenticated through [ACO](/infra/authentication/))
|
| |
- * Ansible role level : through Pull Requests against our [Ansible](/ansible/) roles and/or inventories
|
| |
+ * Application level : granted needed credentials (usually authenticated through [ACO](authentication.md))
|
| |
+ * Ansible role level : through Pull Requests against our [Ansible](../ansible/index.md) roles and/or inventories
|
| |
* Machine/Infra level : granted shell/elevated rights based on Ansible rights
|
| |
|
| |
## Onboarding infra members
|
| |
@@ -24,11 +24,11 @@
|
| |
While being part of the `sig-infra` group doesn't grant any shell/sudo permission *anywhere* , it at least reflect that new person joigning the team will be a PoC for infra and also automatically granted :
|
| |
|
| |
* rights to build/promote pkgs on the [infra koji tags](https://cbs.centos.org/koji/search?match=glob&type=tag&terms=infra*)
|
| |
- * a `@centosproject.org` email address (see also the [postfix](/infra/mailservers) section)
|
| |
+ * a `@centosproject.org` email address (see also the [postfix](mailservers.md) section)
|
| |
|
| |
### Ansible inventory access (for "full" sysadmin)
|
| |
|
| |
- Based on the [Environment](/#available-environments) that new infra team member needs access to (delegation, as some are in charge of CentOS CI but not -yet- other parts, etc), one needs to be added in a specific ansible list/variables in inventory, the [admins_list](https://github.com/CentOS/ansible-role-baseline/blob/master/defaults/main.yml#L5) that contains list of shell accounts to create , with their ssh pub key and if they are granted sudo rights.
|
| |
+ Based on the [Environment](../index.md#available-environments) that new infra team member needs access to (delegation, as some are in charge of CentOS CI but not -yet- other parts, etc), one needs to be added in a specific ansible list/variables in inventory, the [admins_list](https://github.com/CentOS/ansible-role-baseline/blob/master/defaults/main.yml#L5) that contains list of shell accounts to create , with their ssh pub key and if they are granted sudo rights.
|
| |
|
| |
From that point, next time Ansible will be ran across servers fleet (either automatically through central mgmt station *or* manually for the machines in the `manual-run` specific group), it will add the new sysadmin (or modify/remove) on the nodes.
|
| |
|
| |
@@ -47,7 +47,7 @@
|
| |
* have enabled OTP on their account for authentication services
|
| |
|
| |
|
| |
- Once you have verified the GPG public key, you can (for `git-crypt`ed git repositories for ansible, add the new collaborator like this (do this on *each* [git repo](/ansible/topology/) that the new sysadmin is granted access to).
|
| |
+ Once you have verified the GPG public key, you can (for `git-crypt`ed git repositories for ansible, add the new collaborator like this (do this on *each* [git repo](../ansible/topology.md) that the new sysadmin is granted access to).
|
| |
So after you've added the gpg in your own keyring, you can add it to git-crypt
|
| |
|
| |
```
|
| |
This should clean up most of the mkdocs warnings and make the site work when embedded into a larger mkdocs project as well.