diff --git a/docs/buildsys/koji-cbs-sigs.md b/docs/buildsys/koji-cbs-sigs.md index b7e5ae9..20101de 100644 --- a/docs/buildsys/koji-cbs-sigs.md +++ b/docs/buildsys/koji-cbs-sigs.md @@ -159,8 +159,8 @@ Last step is to then play the [stylo](https://github.com/centos/ansible-role-sty -## Koji tags creation - +## CBS Koji tags +### Overview CBS uses a specific naming convention for the koji tags that will be created. It's important that we follow that specific convention because the signing/pushing automated process parses the tags to know which gpg SIG key to use, and where to push content that will appear on the mirror network. @@ -177,6 +177,8 @@ What's the influence of the `tag level` mentioned above ? * testing : processed by signing service but packages aren't signed, and just land on https://buildlogs.centos.org CDN, so just to have publicly available pkgs that can be promoted to `release` by SIG later * release : processed by signing service : packages are gpg signed with SIG key, and content appear on the mirror CDN and can be consummed by all +### Tags creation + To create tags, we have in place a tool that is maintained through ansible-role-kojihub and distributed on the kojihub node itself. That means that to be able to use it, you need to have local shell access and kick the following commands as the `koji` user , *or* eventually have admin rights and kick the tool from outside @@ -218,3 +220,13 @@ Added external repo centos8s-baseos to tag kmods8s-packages-main-el8-build (prio ``` +### Tags modification + +It's always possible to modify some existing tags through standard `koji` (or `cbs` alias) CLI calls. +Example : let's add additional architectures for the Kmods SIG : + +``` +for i in el8-build candidate testing release ; do koji edit-tag --arches="x86_64 ppc64le aarch64" kmods8s-packages-main-${i}; koji taginfo kmods8s-packages-main-${i}|grep Arches ; done +``` + + diff --git a/docs/infra/authentication.md b/docs/infra/authentication.md index e69de29..9819a55 100644 --- a/docs/infra/authentication.md +++ b/docs/infra/authentication.md @@ -0,0 +1,57 @@ +# Authentication service for CentOS Infrastructure + +!!! info + CentOS and Fedora merged their previous authentication backend to a new solution based on [(Free)IPA](http://www.freeipa.org), but it's only valid for applications that *are* able to use such new authentication system (see below for explanations) + + Worth knowing that majority of infra services described below are managed/hosted by Fedora Infra (while CentOS infra is *consuming* such service + + +## Authentication platform components +### IPA servers + +There are actually 3 IPA servers running on RHEL8 that are used as backend authentication solution. +These aren't publicly reachable and are managed/hosted by the Fedora Infra team. + +### Community Portal (noggin) + +The https://accounts.centos.org community portal is based on [Noggin](https://github.com/fedora-infra/noggin) where people can register is an openshift deployment done by Fedora Infra on the Fedora infra openshift cluster. +CentOS Infra team though is in charge of the [haproxy](https://github/centos/ansible-role-haproxy) node in front of openshift and routing requests to correct openshift compute nodes from Fedora infra. +All the needed variables for haproxy are stored in the CentOS ansible inventory, either through group_vars and/or host_vars variables + +Same goes for the TLS certificates used on the haproxy reverse proxy : automatically applied by the ansible role *after* they are renewed through BAU process (see [dedicated TLS](/security/tls/#how-to-renew-existing-certs) documentation) + +### Identity Provider (IdP) + +We deploy our own IdP instance, based on [Ipsilon](https://ipsilon-project.org/) that is publicly available on https://id.centos.org. + +It's full deployed by the [ipsilon](https://github/centos/ansible-role-ipsilon) Ansible role but needs access through fedora network as it's not directly available from outside + +It supports the following standard protocols and uses IPA servers backends for users auth/group memberships and that node is properly enrolled in IPA itself (requirement) + +#### Openid + +Applications using OpenID can point directly to https://id.centos.org and some applications (like https://blog.centos.org) still rely on openid as auth protocol + +#### OpenID Connect/Oauth2 + +OpenIDC is preferred over OpenID but needs some configuration at both IdP and Application side : + + * on https://id.centos.org : login as account with admin right in ipsilon (managed by Ansible inventory), and create new OpenIDC app / client ID / secret / oauth callback (basically original URL callback endpoint) + * on the client application side : reflect all client id / secrets / oauth callback + +#### SAML + +`unused` so far in CentOS Infra, but still available if needed as Ipsilon supports it + +### FASJSON + +[fasjson](https://github.com/fedora-infra/fasjson) API endpoint (available at https://fasjson.fedoraproject.org) permits authenticated users (through kerberos authentication/ticket) to query for users/groups information. +Same remark as for noggin : deployed/maintained by Fedora infra but *crucial* for the following CentOS services : + + * email aliases (computed automatically through fasjson API calls) + * CBS koji access based on group memberships + * letting users retrieve their TLS certificate to auth against some CentOS Infra services + +#### TLS/x509 authentication + +See public [Authentication](https://wiki.centos.org/Authentication) wiki page that covers kerberos/tls (no need to duplicate content here)