adamgoossens / helms-deep Goto Github PK

Need two OIDC mappers - preferred_username and name.

name will be the 'full name' OIDC built-in mapper. This gives a nice user name in the top left of the console when logged in.

Figure out how to create those mappers in the KeycloakClient CR, if it's actually possible.

ACS is deployed empty, so far. Adjust the automation to automatically add the hosting cluster as a monitored cluster for ACS.

Deploy AAP on the Supervisor cluster. Need more detail here.

To use the log forwarding API, we need the logging operator in the supervisor cluster. Add it to the bootstrap playbook.

Determine what config changes are necessary to integrate ACM with the SSO realm. Make those changes so that ACM authenticates users against the SSO realm.

ACM needs a Git source to pull from for its channels. Using the helms-deep-resources repository isn't suitable, as if we want to demonstrate synchronisation with Git we need something that we can modify and update.

Use the Gitea operator (or upstream equivalent) to deploy Gitea on the supervisor cluster during bootstrap.

We'll use this as the source of truth for both:

• Ansible Tower Projects
• ACM application resources

We'll use Gitea to import the upstream repositories as the 'base' repositories. Then the demonstrators can modify the repositories locally as much as they want.

Deploy an empty ELK stack on the supervisor cluster, separate to the stack used by the logging operator. This is to simulate an external sink for audit/log data (e.g. Splunk).

Satellite clusters, and the supervisor cluster, would have their LogForwarding API to push to this ELK stack.

Determine how to enable SSO via OIDC in ACS; make those changes to have ACS authenticate to the SSO realm.

A new KeycloakClient and associated secret will be needed.

Per the title. Don't allow randoms who have logged in to be able to create projects - or, indeed, to see anything.