Eventing Auth Manager is a central component that is deployed in Kyma Control Plane (KCP). The component manages applications in the SAP Cloud Identity Services - Identity Authentication by creating and deleting them based on the creation or deletion of a managed Kyma runtime.
For more information, see the /contributor folder.
You must have a Kubernetes cluster. You can use KIND to get a local cluster for testing purposes, or use a remote one.
Your controller automatically uses the current context in your kubeconfig file. To check your current context, run
kubectl cluster-info.
To run the controller locally, you need to have two clusters available. One cluster is used to run the controller, and the other cluster is used as a target for the created Secret.
-
Create the namespace to deploy the manager and the SAP Cloud Identity Services - Identity Authentication credential Secret:
kubectl create ns kcp-system
-
Create the Secret for the SAP Cloud Identity Services - Identity Authentication credentials specified by:
-
TEST_EVENTING_AUTH_IAS_USER -
TEST_EVENTING_AUTH_IAS_PASSWORD -
TEST_EVENTING_AUTH_IAS_URLkubectl create secret generic eventing-auth-ias-creds -n kcp-system --from-literal=username=$TEST_EVENTING_AUTH_IAS_USER --from-literal=password=$TEST_EVENTING_AUTH_IAS_PASSWORD --from-literal=url=$TEST_EVENTING_AUTH_IAS_URL
-
Create the Secret containing the kubeconfig of the cluster on which the
eventing-webhook-authSecret is created by specifyingPATH_TO_TARGET_CLUSTER_KUBECONFIGandKYMA_CR_NAME.kubectl create secret generic kubeconfig-$KYMA_CR_NAME -n kcp-system --from-file=config=$PATH_TO_TARGET_CLUSTER_KUBECONFIG
Create the namespace in which the eventing-webhook-auth Secret is created in the target cluster:
kubectl create ns kyma-system-
Install the Kyma and EventingAuth Custom Resource Definitions (CRDs):
make install
-
Update the name of the custom resource (CR) in
config/samples/operator_v1beta2_kyma.yamlto contain the name of the kubeconfig secret created in Preparing the clusters. The Kyma CR name is the same as the target Kubernetes cluster name. -
Install the CRs instances:
kubectl apply -f config/samples/
-
Build and push your image to the location specified by
IMG:make docker-build docker-push IMG=<some-registry>/eventing-auth-manager:tag
-
Deploy the controller to the cluster with the image specified by
IMG:make deploy IMG=<some-registry>/eventing-auth-manager:tag
To delete the CRDs from the cluster, run:
make uninstallTo undeploy the controller from the cluster, run:
make undeployTo execute the tests, run:
make testBy default, the integration tests use a stub for the SAP Cloud Identity Services - Identity Authentication API. This stub returns. It's also possible to use the real SAP Cloud Identity Services - Identity Authentication API by setting all the following environment variables:
export TEST_EVENTING_AUTH_IAS_URL=https://my-tenant.accounts.ondemand.com
export TEST_EVENTING_AUTH_IAS_USER=user@sap.com
export TEST_EVENTING_AUTH_IAS_PASSWORD=passwordBy default, the integration tests use a local control plane created by envtest.
It's also possible to use a real target cluster by setting the following environment variable:
# The path to the kubeconfig of the cluster
export TEST_EVENTING_AUTH_TARGET_KUBECONFIG_PATH=/some/path/.kube/configThis project aims to follow the Kubernetes Operator pattern.
It uses Controllers, which provide a reconcile function responsible for synchronizing resources until the desired state is reached on the cluster.
For general contributing guidelines, see the Contributing Rules.
-
Install the CRDs into the cluster:
make install
-
In a new terminal window, run your controller:
make run
You can also trigger both operations by running:
make install run.
If you are editing the API definitions, generate the manifests, such as CRs or CRDs, using the following command:
make manifestsRun
make --helpfor more information on all potentialmaketargets.
For more information, see the official Kubebuilder documentation.
See the Code of Conduct document.
See the license file.