This operator is in charge of configuring the idp client service. It will also install the dex operator.
Please fork this repo and clone from the fork. All your work should be against the forked repo.
make test
make functional-test-full
You must meet the following requirements:
- OpenShift Container Platform (OCP) 4.6+
oc
(ver. 4.6+)kustomize
(ver. 4.2.0+)
oc cluster-info
This is required for the Dex server we will be using under the covers to authenticate the managed clusters OpenID OAuth requests. The quickest way to do this is using a tool from https://github.com/open-cluster-management/sre-tools/wiki/ACM---Day-1#add-an-acme-certificate.
Here is a summary of the commands you need to run for an AWS based hub:
- Clone the acmesh-official repo and setup AWS account environment variables
export AWS_ACCESS_KEY_ID={your AWS Access Key ID}
export AWS_SECRET_ACCESS_KEY={your AWS Secret Access Key}
cd /tmp
git clone https://github.com/acmesh-official/acme.sh.git
cd acme.sh
- Query OCP to setup some environment variables
export API=$(oc whoami --show-server | cut -f 2 -d ':' | cut -f 3 -d '/' | sed 's/-api././')
export WILDCARD=$(oc get ingresscontroller default -n openshift-ingress-operator -o jsonpath='{.status.domain}')
- If this is the first time running acme.sh, register your email address
./acme.sh --register-account -m {your email address}
- Generate the certificate
./acme.sh --issue --dns dns_aws -d ${API} -d "*.${WILDCARD}"
- Apply the certificate to OCP
pushd ${PWD}
cd ${HOME}/.acme.sh/${API}
oc create secret tls router-certs --cert=fullchain.cer --key=${API}.key -n openshift-ingress
oc patch ingresscontroller default -n openshift-ingress-operator --type=merge --patch='{"spec": { "defaultCertificate": { "name": "router-certs" } } }'
popd
After running these commands, various pods on the OCP hub will restart in order to use the new certificate. Wait a while, sometimes 10-20 minutes for all the required pods to restart. The OCP UI Overview page can be used to check the overall health of OCP. The Status section will show which operators are updating due to the certificate update.
NOTE: To use the ACME certificate process, you must have Amazon AWS credentials to allow a Route53 domain to be added for certificate verification during creation.
Use GitHub as the OAuth provider.
-
On github.com, go to Settings > Developer Settings > OAuth Apps (The shortcut is https://github.com/settings/developers)
-
Add a
New OAuth App
. Copy theClient ID
andClient Secret
values. You will need them later on. -
Fill in the
Application name
with something to help identify the owner and hub it will be used for. NOTE: If you have more than one hub, each one will need it's own entry. -
Fill in
Homepage URL
andAuthorization callback URL
with the hub console URL.
(NOTE: A little bit later we will correct theAuthorization callback URL
value once we have the generated value.) -
Click
Register Application
NOTE: You will need to return to the GitHub OAuth a little bit later to correct the Authorization callback URL
, once the value is generated for you.
- Fork and clone this repo
git clone https://github.com/<git username>/idp-mgmt-operator.git
cd idp-mgmt-operator
- Login to Red Hat Advanced Cluster Management or Multi Cluster Engine hub
- Verify you are logged into the hub cluster
oc cluster-info
- From the cloned idp-mgmt-operator directory:
make deploy
- Verify the pods are running
There are two pods that should be running:
- idp-mgmt-operator-controller-manager
- idp-mgmt-operator-webhook-service
Check using the following command:
oc get pods -n idp-mgmt-config
NOTE: To install via the catalog, you must be on OpenShift 4.8.12 or newer due to this OLM bug - a backport to OCP 4.7 is in progress.
If you built an operator bundle and catalog as documented later, or if you wish to use the latest published operator bundle and catalog to deploy:
- Login to Red Hat Advanced Cluster Management or Multi Cluster Engine hub
- Verify you are logged into the hub cluster
oc cluster-info
- From the idp-mgmt-operator directory run
make deploy-catalog
- this will create a CatalogSource on your cluster. - Create a subscription to the operator via the OperatorHub UI or by applying a subscription to the Operator - which looks something like:
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: idp-mgmt-operator
namespace: idp-mgmt-config
spec:
channel: alpha
installPlanApproval: Automatic
name: idp-mgmt-operator
source: idp-mgmt-config-catalog
sourceNamespace: idp-mgmt-config
startingCSV: idp-mgmt-operator.v0.1.1
- Wait for the operator to install - then move on to the next step!
We need to create a few custom resources to get idp-mgmt-operator to trigger. Use the generate-cr.sh
script in
the hack
directory to generate a yaml file with all the CRs needed.
- Setup the required environment variables:
export GITHUB_APP_CLIENT_ID={your GitHub App Client ID}
export GITHUB_APP_CLIENT_SECRET={your GitHub App Client Secret}
export GITHUB_APP_CLIENT_ORG={your GitHub organization}
export IDP_NAME=sample-idp
export AUTHREALM_GITHUB_NAME=authrealm-sample-github
export AUTHREALM_GITHUB_NS=authrealm-sample-github-ns
- Verify you are logged into the hub cluster
oc cluster-info
- run the script
cd hack
./generate-cr.sh
The generates-cr.sh
script will create the yaml and output the name of the yaml file. In addition, it will
provide values that need to be copied back into the GitHub Auth App.
A list of labels will also be displayed which will need to be added to the managed cluster to add it to the cluster set.
-
Select the OAuth App you had created above
-
Correct the
Authorization callback URL
with the value displayed in theAuthorization callback URL
output produced from running thegenerates-cr.sh
script. -
Click
Update application
Apply the custom resources using the yaml generated by the generates-cr.sh
script
- Verify you are logged into the hub cluster
oc cluster-info
- Apply the YAML
oc apply -f {your YAML file}
A managed cluster is needed so that the OAuth policy can be configured by idp-mgmt-operator. Make sure you have a managed cluster defined in the hub.
Use the labels displayed by the generate-cr.sh
script and add them to the managed cluster.
oc label managedclusters {managed cluster name} {key=value}
It will take a little while for the Placement to cause a ManifestWork to be generated and applied to the managed cluster. You can monitor the managed cluster's OAuth CR to see if the new OAuth entry appears. Once the entry appears, you can logout of the managed cluster and when you attempt to login, the new OAuth option will appear on the login screen.
If you want to undo the OAuth on the managed cluster, remove the labels you added and the managed cluster will be removed from the cluster set.
oc label managedclusters {managed cluster name} {key}-
To delete the custom resources using the yaml generated by the generates-cr.sh
script
oc delete -f {your YAML file}
make undeploy
You can build and push an operator bundle and installable catalog for this operator, which will allow you to apply a CatalogSource to your cluster and install via the OperatorHub UI or via an Operator Subscription object.
To build and publish a bundle and catalog:
- [IMPORTANT] Use your own registry! Do the following to enable you to use your own registry and create repos in your quay.io org (your user org) named
idp-mgmt-operator-bundle
andidp-mgmt-operator-catalog
and, if so,
export IMAGE_TAG_BASE=quay.io/\<your-user\>/idp-mgmt-operator
If you don’t do this, you need push permissions to identitatem - and you’ll push straight to the source identitatem org. - Which only the build system should do!
You might need to make these personal repos public to allow the images to be downloaded by OLM
- Set the VERSION as a timestamp. For example:
export VERSION=`date -u "+0.0.0-%Y%m%d-%H-%M-%S"`
- If you want to use a specific idp-mgmt-operator image, set the IMG environment variable to that image. For example, to point to a PR built image:
export IMG=quay.io/identitatem/idp-mgmt-operator@sha256:f1303674fc463cbc3834d3dd6c9d023cc991144a3e170c496dac5d2a44459d5c
Otherwise use:
export IMG=quay.io/identitatem/idp-mgmt-operator:latest
export
DOCKER_USER and DOCKER_PASS equal to a docker user and password that will allow you to push to the quay repositories outlined in step 1.- run
make publish
- this should acquire any dependencies and push to quay! - To test, run
make deploy-catalog
. This will create a catalogsource on your hub cluster and you can install the test catalog from OperatorHub.
We have a GitHub action defined to generate a tagged bundle and catalog image when a SemVer GitHub tag is created on this repo. To create a new release that will generate a versioned Bundle/Catalog there are two methods:
- Run the following command to generate the value we will use as part of the release and tag for non-shipped releases
date -u "+0.0.0-%Y%m%d-%H-%M-%S"
If you are building a release candidate, the format should be 0.1.1-rc#. (Where # is the release candidate number. Do not use UPPERCASE characters!) If you are building the final release, the format should be 0.1.1.
- Go to dex-operator github page and select Releases (https://github.com/identitatem/dex-operator/releases)
- Select Draft a new release
- For Release title, enter v and then paste the value from the date command above
- Select Choose a tag
- In the Find or create a new tag field, paste the value from the date command above
- Select Create new tab on publish
- Select Publish release. This will cause a github action to start. Once the github action is complete, move on to the next part which will pull the new dex-operator quay image from https://quay.io/repository/identitatem/dex-operator?tab=tags into the idp-mgmt-operator.
- In your fork of the https://github.com/identitatem/idp-mgmt-operator repo, create a new branch
- Update
go.mod
entrygithub.com/identitatem/dex-operator
to reference the new tag, for examplegithub.com/identitatem/dex-operator 0.0.0-20211028-14-34-26
- Run
go mod tidy
. Thego.mod
entry will be updated to the correct value. - Update https://github.com/identitatem/idp-mgmt-operator/blob/main/config/manager/manager.yaml so RELATED_IMAGE_DEX_OPERATOR points to the new dex-operator image in quay.
- Export IMG variable to point to latest
export IMG=quay.io/identitatem/idp-mgmt-operator:latest
- Run
make bundle
to update https://github.com/identitatem/idp-mgmt-operator/blob/main/bundle/manifests/idp-mgmt-operator.clusterserviceversion.yaml. - Test the changes using
make test
thenmake deploy
and apply and AuthRealm to a managed cluster and be sure it works. - Commit the PR changes and get them reviewed and merged.
- Run the following command to generate the value we will use as part of the release and tag (OR possibly use the same tag dex-operator used)
date -u "+0.0.0-%Y%m%d-%H-%M-%S"
If you are building a release candidate, the format should be 0.1.1-rc#. (Where # is the release candidate number. Do not use UPPERCASE characters!) If you are building the final release, the format should be 0.1.0.
- Go to idp-mgmt-operator github page and select Releases (https://github.com/identitatem/idp-mgmt-operator/releases)
- Select Draft a new release
- For Release title, enter v and then paste the value from the date command above
- Select Choose a tag
- In the Find or create a new tag field, paste the value from the date command above
- Select Create new tab on publish
- Select Publish release. This will cause a github action to start. Once the github action is complete a new Operator Hub catalog will be available at https://quay.io/repository/identitatem/idp-mgmt-operator-catalog?tab=tags which you can reference in your catalog source.
git tag <semver-tag>
git push --tags
- Wait for the GitHub Action to complete.
- The action will create and push an idp-mgmt-operator-bundle and idp-mgmt-operator-catalog image and push to quay, tagged with the same SemVer tag you applied to the GitHub repo to generate that release.
In order to deploy this version - follow the Catalog deploy method but set:
VERSION=<semver-tag>
IMG_TAG=<semver-tag>