Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configure Bundle CA Cert if provided #144

Merged
merged 2 commits into from
Nov 8, 2023

Conversation

rooftopcellist
Copy link
Member

@rooftopcellist rooftopcellist commented Nov 8, 2023

Summary

When deploying EDA into an environment where a private Git server is in use with private CA-signed certificates in front of it, EDA worker pods fail to git clone... when Git projects are defined.

The awx-operator allows for private CA-signed certs via the bundle_cacert_secret property in the AutomationController CRD. This PR adopts the same pattern for the EDA-server-operator.

Docs for Trusting a Custom Certificate Authority

In cases which you need to trust a custom Certificate Authority, there are few variables you can customize for the awx-operator.

Trusting a custom Certificate Authority allows the EDA to access network services configured with SSL certificates issued locally, such as cloning a project from from an internal Git server via HTTPS. It is common for these scenarios, experiencing the error unable to verify the first certificate.

Please note the eda-server-operator will look for the data field ldap-ca.crt in the specified secret when using the ldap_cacert_secret, whereas the data field bundle-ca.crt is required for bundle_cacert_secret parameter.

Example of customization could be:

---
spec:
  ...
  bundle_cacert_secret: <resourcename>-custom-certs

Create the secret with CLI:

  • Certificate Authority secret
# kubectl create secret generic <resourcename>-custom-certs \
    --from-file=ldap-ca.crt=<PATH/TO/YOUR/CA/PEM/FILE>  \
    --from-file=bundle-ca.crt=<PATH/TO/YOUR/CA/PEM/FILE>

@rooftopcellist
Copy link
Member Author

I just tested this out and all deployments template correctly and the application deploys. I tested with bundle_cacert_secret specified on the spec, and without.

Signed-off-by: Christian M. Adams <chadams@redhat.com>
@the-it-jaeger
Copy link

I'm looking forward to this one being merged and delivered with the next version of AAP :) 🤞

Copy link
Contributor

@Alex-Izquierdo Alex-Izquierdo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

| image_version | Image version to pull | main |
| image_web | Path of the image to pull | quay.io/ansible/eda-ui |
| image_web_version | Image version to pull | latest |
| image_pull_policy | The pull policy to adopt | IfNotPresent |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related with the PR, but should this be better "latest" specially when we are using images that point to latest? (it means are potentially upgradable)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, so for quay.io/ansible/eda-server, latest is latest tagged release. And main is the latest commit in the main branch.

So like you said, we should use latest in the operator defaults for that reason (more stable). I just updated the PR to reflect that in the defaults.

@rooftopcellist rooftopcellist merged commit 959e20c into ansible:main Nov 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants