Having one cluster doing stuff every five minutes is OK. Having hundreds of clusters doing the same thing every five minutes can become an issue if that thing is contacting one and the same remote system (like it is the case with the LDAP sync). Also having hundreds of things on one cluster running in the same intervals results in CPU usage spikes.

Context

For APPUiO Managed we grant some customer users "admin" rights on the clusters. These rights ideally are identical to the ones granted to the sudoers group via this component. Currently we do this with adhoc configs.

But manually maintaining adhoc configs misses changes like #42 and #61 .

By having an option to add additional sudoers groups, this could be managed via this component.

Alternatives

Keep doing it with adhoc-configs

Steps to Reproduce the Problem

1. Login with sudoers credentials to openshift console
2. In Administrator View; Navigate to Observe -> Alerting -> Silences
3. (optional) crate a silence

Actual Behavior

Silences aren't displayed:

Expected Behavior

Silences are displayed

The implementation in #1 uses the role cluster-admin to give permission for the LDAP group sync. This is probably too much power.

Find the minimal required permission and use them instead of role clsuter-admin.

As of the time of this writing, only LDAP is supported.

Context

In #1 we implemented LDAP group sync. Since we'll move away from LDAP as authentication provider (to OIDC) we'll need another way to manage the groups.
Implement the feature in this component to manage user groups:
It should be possible to assign a list of usernames to a certain group. For example all VSHN users can be mapped to the "VSHN openshiftroot" group that way. Additionally this allows also customers to introduce groups of their own users.

Alternatives

Using LDAP group sync is currently the only option to manage user groups in OpenShift.

Acceptance Criteria

• Given a hierarchy, when defining the group memberships in the tenant level (or higher up), then the RBAC groups are created for all clusters that are part of the hierarchy.
• Given a defined group memberships in a hierarchy, when a specific user is removed/nullified from a group on a more specific level (e.g. cluster), then the specific user is not in the RBAC group.
• Given a defined group memberships in a hierarchy, when an additional user is added to a group, then the RBAC group includes the given user.
• Given a defined group memberships in a hierarchy, when the group is removed/nullified in lower level of the hierarchy, then the RBAC group will not be created

This issue provides visibility into Renovate updates and their statuses. Learn more

This repository currently has no open or pending branches.

• Check this box to trigger a request for Renovate to run again on this repository

See https://docs.openshift.com/container-platform/4.4/authentication/ldap-syncing.html#ldap-syncing-pruning_ldap-syncing-groups

https://hub.syn.tools/openshift4-authentication/references/parameters.html is missing

Steps to Reproduce the Problem

1. Login to cluster
2. oc describe node c-mist-sg7hn-m-0.europe-west6-a.c.ocp4-poc.internal

Actual Behavior

The request fails with Error from server (Forbidden): nodes "c-mist-sg7hn-m-0.europe-west6-a.c.ocp4-poc.internal" is forbidden: User "simon.ruegg" cannot get resource "nodes" in API group "" at the cluster scope

Expected Behavior

View right is granted on more resources for operations.
Especially get and list would be helpful on the following resources:

• nodes
• machinesets
• machines
• machineconfigpools
• machineconfigs
• apiservices
• persistentvolumes
• podsecuritypolicies
• syncconfigs
• ingresscontroller
• ...
  (To be extended)

For each of these resources we have to first double check if it's ok to make them viewable without compromising security.

• CHANGELOG.md
• CONTRIBUTING.md
• BSD-3 License
• Bootstrap documentation
• GitHub actions for testing
• GitHub Issue/PR templates

Context

Once the auth provider is set up correctly, including all RBAC rules, the kubeadmin superuser should be removed from the cluster.
See https://docs.openshift.com/container-platform/4.4/authentication/remove-kubeadmin.html#removing-kubeadmin_removing-kubeadmin

This requires a break glass mechanism to be in place for the case that impersonation and/or the login provider is not available.

Summary

As an engineer running an LDAP server secured by a certificate signed by a public CA
I want to be able to change the certificate for the LDAP server without having to touch the LDAP IdP config on all OCP4 clusters
So that certificate changes are as painless as possible.

Context

Currently, to configure and LDAP identity provider, users must provide the LDAP server's CA certificate. This is used for both the OpenShift authentication config and the LDAP group sync cronjob.

However, the OpenShift authentication setup works fine without providing the LDAP server's CA certificate, if the server uses a certificate signed by a CA which is part of OpenShift's trusted system CA bundle. However, to ensure the openshift authentication uses the system CA bundle, we need to ensure that we don't configure the LDAP IdP ca field, as otherwise the oauth pods use the contents of that field instead of the system CA bundle.

The OCP trusted CA bundle can be made available by creating an empty configmap with the label config.openshift.io/inject-trusted-cabundle="true".

Out of Scope

—

Further links

• OCP4 LDAP IdP docs: https://docs.openshift.com/container-platform/4.8/authentication/identity_providers/configuring-ldap-identity-provider.html

Acceptance criteria

• Given that I configure an LDAP IdP for an LDAP server which uses a certificate signed by a public CA, I don't have to provide the CA certificate in the component configuration, and the resulting configuration instead uses the OpenShift system trusted CA bundle.
• Given that I don't configure a custom CA certificate for an LDAP IdP, the resulting oauth config for that LDAP IdP doesn't contain the ca field.
• Given that I don't configure a custom CA certificate for an LDAP IdP, the group sync cronjob for that LDAP IdP uses the system trusted CA bundle to verify the LDAP server's certificate

Implementation Ideas

• Adjust code in component/ldap.jsonnet to create a configmap with label config.openshift.io/inject-trusted-cabundle="true" to get a configmap containing the OCP4 system CA bundle for the group sync cronjob and make sure the cronjob is using that configmap when no custom CA is provided for the LDAP server. Make sure ArgoCD doesn't complain about the changing contents of the system CA bundle configmap.
• Ensure that the LDAP IdP entry in the oauth object doesn't have the ca key, if no custom CA is provided.