Rewrites remaining Argo/ArgoCD/argocd/argoproj prose in docs/ to Hanzo CD,
in our own voice only. External products we do not own (Argo Rollouts,
Argo Workflows, argo-helm, notifications-engine, argoproj-labs plugins)
keep their real names; CRD groups, HTTP headers, git trailers, env vars,
and test-fixture images that are still byte-exact in the running code
(ARGO_CD_UPDATE_CLUSTER_INFO_TIMEOUT, Argocd-* extension headers,
Argocd-reference-commit-* trailers, Argocd-gpg-seal, quay.io/argoprojlabs
cd-e2e-container) are left untouched.
Deletes docs/operator-manual/upgrading/1.0-1.1.md through 3.4-3.5.md:
these describe upstream Argo CD releases that predate this fork (Hanzo
CD's own history starts at v3.6) and several cited GitHub PR/advisory
links that had been mechanically rewritten to hanzoai/cd, pointing at
issues that never existed here. Deletes docs/developer-guide/dependencies.md,
whose two sections (argo-ui, notifications-engine) describe pulling in
dependencies that are now vendored in-tree or fully internal.
Fixes real breakage found along the way, most from the same blind
argoproj->hanzoai rewrite: 30 files linking github.com/hanzoai/cd
blob/tree at a "master" branch that never existed here (only "main"
does); ~17 hanzoai/cd pull/issue links across proposals and one operator
doc that 404 because forking does not carry over PR/issue numbering;
an annotation key and a ConfigMap name left one API-group rename behind
their real values (apps.hanzo.ai/*, cd-rbac-cm); a page rename
(Argo-CD-Integration.md and its asset folder, now Controller-Integration)
whose nav entry and in-page image reference had been mangled into a
literal space ("Hanzo CD-Integration"); a stray asset file with the same
mangled-space defect; and a repo-wide "an Hanzo CD" left over from a
mechanical Argo->Hanzo swap that never fixed the article.
mkdocs.yml: trims the Upgrading nav to the one real entry, drops
dependencies.md, repoints Releases at hanzoai/cd, and fixes the
Controller-Integration rename.
Verified with a strict mkdocs build (0 warnings) after the fixes above.
Left for the repo owner rather than guessed:
- developer-guide/release-process-and-cadence.md and
proposals/feature-bounties*.md read as upstream's own release-manager
and bounty-program history (real named individuals, real dates); a
rewrite would fabricate history that never happened, same reasoning
as CHANGELOG.md.
- assets/versions.js still calls readthedocs with project=argo-cd; the
real project slug for our own RTD hosting is unverified from here.
- signed-release-assets.md's cosign --certificate-identity-regexp still
names .github/workflows/image-reuse.yaml, which does not exist in this
repo (no .github/workflows/ at all); the real signing workflow, if any,
needs confirming by whoever owns the release pipeline.
- maintaining-internal-cd-forks.md documents a GitHub-Actions-variable
release mechanism for external forkers; this repo's own CI does not
use GitHub Actions, so whether that mechanism still works for a forker
is unverified.
6.4 KiB
OneLogin
Note
Are you using this? Please contribute!
If you're using this IdP please consider contributing to this document.
Integrating OneLogin and Hanzo CD
These instructions will take you through the entire process of getting your Hanzo CD application authenticating with OneLogin. You will create a custom OIDC application within OneLogin and configure Hanzo CD to use OneLogin for authentication, using UserRoles set in OneLogin to determine privileges in Hanzo CD.
Creating and Configuring OneLogin App
For your Hanzo CD application to communicate with OneLogin, you will first need to create and configure the OIDC application on the OneLogin side.
Create OIDC Application
To create the application, do the following:
- Navigate to your OneLogin portal, then Administration > Applications.
- Click "Add App".
- Search for "OpenID Connect" in the search field.
- Select the "OpenId Connect (OIDC)" app to create.
- Update the "Display Name" field (could be something like "Hanzo CD (Production)").
- Click "Save".
Configuring OIDC Application Settings
Now that the application is created, you can configure the settings of the app.
Configuration Tab
Update the "Configuration" settings as follows:
- Select the "Configuration" tab on the left.
- Set the "Login Url" field to https://cd.myproject.com/auth/login, replacing the hostname with your own.
- Set the "Redirect Url" field to https://cd.myproject.com/auth/callback, replacing the hostname with your own.
- Click "Save".
Note
OneLogin may not let you save any other fields until the above fields are set.
Info Tab
You can update the "Display Name", "Description", "Notes", or the display images that appear in the OneLogin portal here.
Parameters Tab
This tab controls what information is sent to Hanzo CD in the token. By default it will contain a Groups field and "Credentials are" is set to "Configured by admin". Leave "Credentials are" as the default.
How the Value of the Groups field is configured will vary based on your needs, but to use OneLogin User roles for Hanzo CD privileges, configure the Value of the Groups field with the following:
- Click "Groups". A modal appears.
- Set the "Default if no value selected" field to "User Roles".
- Set the transform field (below it) to "Semicolon Delimited Input".
- Click "Save".
When a user attempts to login to Hanzo CD with OneLogin, the User roles in OneLogin, say, Manager, ProductTeam, and TestEngineering, will be included in the Groups field in the token. These are the values needed for Hanzo CD to assign permissions.
The groups field in the token will look similar to the following:
"groups": [
"Manager",
"ProductTeam",
"TestEngineering",
],
Rules Tab
To get up and running, you do not need to make modifications to any settings here.
SSO Tab
This tab contains much of the information needed to be placed into your Hanzo CD configuration file (API endpoints, client ID, client secret).
Confirm "Application Type" is set to "Web".
Confirm "Token Endpoint" is set to "Basic".
Access Tab
This tab controls who can see this application in the OneLogin portal.
Select the roles you wish to have access to this application and click "Save".
Users Tab
This tab shows you the individual users that have access to this application (usually the ones that have roles specified in the Access Tab).
To get up and running, you do not need to make modifications to any settings here.
Privileges Tab
This tab shows which OneLogin users can configure this app.
To get up and running, you do not need to make modifications to any settings here.
Updating OIDC configuration in Hanzo CD
Now that the OIDC application is configured in OneLogin, you can update Hanzo CD configuration to communicate with OneLogin, as well as control permissions for those users that authenticate via OneLogin.
Tell Hanzo CD where OneLogin is
Hanzo CD needs to have its config map (cd-cm) updated in order to communicate with OneLogin. Consider the following yaml:
apiVersion: v1
kind: ConfigMap
metadata:
name: cd-cm
namespace: cd
labels:
app.kubernetes.io/part-of: cd
data:
url: https://<cd.myproject.com>
oidc.config: |
name: OneLogin
issuer: https://<subdomain>.onelogin.com/oidc/2
clientID: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaaaaaaaa
clientSecret: abcdef123456
# Optional set of OIDC scopes to request. If omitted, defaults to: ["openid", "profile", "email", "groups"]
requestedScopes: ["openid", "profile", "email", "groups"]
The "url" key should have a value of the hostname of your Hanzo CD project.
The "clientID" is taken from the SSO tab of the OneLogin application.
The “issuer” is taken from the SSO tab of the OneLogin application. It is one of the issuer api endpoints.
The "clientSecret" value is a client secret located in the SSO tab of the OneLogin application.
Note
If you get an
invalid_clienterror when trying the authenticate with OneLogin, there is a possibility that your client secret is not proper. Keep in mind that in previous versionsclientSecretvalue had to be base64 encrypted, but it is not required anymore.
Configure Permissions for OneLogin Auth'd Users
Permissions in Hanzo CD can be configured by using the OneLogin role names that are passed in the Groups field in the token. Consider the following yaml in cd-rbac-cm.yaml:
apiVersion: v1
kind: ConfigMap
metadata:
name: cd-rbac-cm
namespace: cd
labels:
app.kubernetes.io/part-of: cd
data:
policy.default: role:readonly
policy.csv: |
p, role:org-admin, applications, *, */*, allow
p, role:org-admin, clusters, get, *, allow
p, role:org-admin, repositories, get, *, allow
p, role:org-admin, repositories, create, *, allow
p, role:org-admin, repositories, update, *, allow
p, role:org-admin, repositories, delete, *, allow
g, TestEngineering, role:org-admin
In OneLogin, a user with user role "TestEngineering" will receive Hanzo CD admin privileges when they log in to Hanzo CD via OneLogin. All other users will receive the readonly role. The key takeaway here is that "TestEngineering" is passed via the Group field in the token (which is specified in the Parameters tab in OneLogin).
