Create an integration to manage access to GitHub repositories and roles
GitHub is a code hosting and collaboration platform that enables developers to manage project versions, track changes, and collaborate on software development.
Through this integration, Apono helps you securely manage access to your GitHub repositories, organizational, team and owner roles.
You can also use the steps below to integrate with Apono using Terraform.
In step 11, instead of clicking Confirm, follow the Are you integrating with Apono using Terraform? guidance.
Follow these steps to complete the integration:
On the tab, click GitHub. The Connect Integration page appears.
Under Discovery, select one or multiple resource types.
Click Next. The Apono connector section expands.
From the dropdown menu, select a connector. Choosing a connector links Apono to all the services available on the account where the connector is located.
If the desired connector is not listed, click + Add new connector and follow the instructions for creating a connector (, , , ).
Click Next. The Integration Config page appears.
Define the Integration Config settings.
Now that you have completed this integration, you can that grant permission to your GitHub instance.
Click Next. The Secret Store section expands.
Click Next. The Get more with Apono section expands.
Define the Get more with Apono settings.
Credential Rotation
(Optional) Number of days after which the database credentials must be rotated Learn more about the .
User cleanup after access is revoked (in days)
(Optional) Defines the number of days after access has been revoked that the user should be deleted
Learn more about .
Custom Access Details
(Optional) Instructions explaining how to access this integration's resources Upon accessing an integration, a message with these instructions will be displayed to end users in the User Portal. The message may include up to 400 characters. To view the message as it appears to end users, click Preview.
Integration Owner
(Optional) Fallback approver if no is found Follow these steps to define one or several integration owners:
From the Attribute dropdown menu, select User or Group under the relevant identity provider (IdP) platform.
From the Value dropdown menu, select one or multiple users or groups.
NOTE: When Resource Owner is defined, an Integration Owner must be defined.
Click Confirm.
Make any additional edits.
Deploy the code in your Terraform.
Refer to Integration Config Metadata for more details about the schema definition.
Apono Connector
On-prem connection serving as a bridge between a GitHub database instance and Apono:
Minimum Required Version: 1.3.2
GitHub Organization Account
GitHub organization account that possesses admin repository and user permissions
Company Email of User
(Non-Enterprise subscription) Company email associated with the user's GitHub profile
For non-Enterprise organizations, set the user email to public in GitHub.
If the email is private, Apono will not be able to locate the user.
Synced IdP
(Enterprise subscription) Identity provider (IdP) connected with your GitHub account
For Enterprise organizations, sync GitHub with your IdP.
GitHub Token
GitHub authentication token Under Select scopes, click the checkboxes next to the following parent scopes. By selecting each parent scope, all the children scopes will also be selected:
repo
admin:org
user
Apono Secret
Value generated in one of the following environments
Create a secret for the GitHub instance. For the key, use token. For the value, use the generated GitHub token.
"token": "<GITHUB_ACCESS_TOKEN>"
Apono does not store credentials. The Apono Connector uses the secret to communicate with services in your environment and separate the Apono web app from the environment for maximal security.
Integration Name
Unique, alphanumeric, user-friendly name used to identify this integration when constructing an access flow
Organization
GitHub organization name
Resource Owner
(Optional) Group or role responsible for managing access approvals or rejections for the resource Follow these steps to define one or several resource owners:
Enter a Key name. This value is the name of the tag created in your cloud environment.
From the Attribute dropdown menu, select an attribute under the IdP platform to which the key name is associated. Apono will use the value associated with the key (tag) to identify the resource owner. When you update the membership of the group or role in your IdP platform, this change is also reflected in Apono.
NOTE: When this setting is defined, an Integration Owner must also be defined.
Create an integration to manage access to a Rancher instance
Rancher is a Kubernetes management platform that simplifies the deployment and management of clusters across any environment, enhancing flexibility, scalability, and resource efficiency.
Through this integration, Apono helps you discover your Kubernetes resources and securely manage access through your Rancher instance.
Follow these steps to create a dedicated user for Apono:
In Rancher, with a user-friendly name, such as apono-provisionser-user-role.
Locate the new role.
Click ☰ > Edit YAML.
Above the metadata property, add the cluster-owner role.
Assigning the cluster-owner role via inheritedClusterRoles does not provide access to the local cluster (the Rancher control plane cluster). This role inheritance applies only to downstream user clusters and excludes Rancher’s internal management plane.
Click Save.
with a user-friendly name, such as apono-provisioner-user.
Assign the new dedicated user (apono-provisioner-user) to the new local user.
Logged in as the new dedicated user (apono-provisioner-user), and copy the Access Key and Secret Key.
You can now .
You can also use the steps below to integrate with Apono using Terraform. In step 10, instead of clicking Confirm, follow the Are you integrating with Apono using Terraform? guidance.
Follow these steps to complete the integration:
On the tab, click Rancher. The Connect Integration page appears.
Under Discovery, click Next. The Apono connector section expands.
From the dropdown menu, select a connector.
If the desired connector is not listed, click + Add new connector and follow the instructions for creating a connector (, , , ).
Click Next. The Integration Config section expands.
Define the Integration Config settings.
Now that you have completed this integration, you can that grant permission to your Rancher instance.
API Groups: management.cattle.io
Create a secret for the dedicated user to use during the Apono integration setup. Use the values from step 7 to generate the secret.
Port
Rancher port value
Certificate Authority (optional)
(Optional) Ensures that the Kubernetes API server you are communicating with is trusted and authentic
Leave this field blank to connect the cluster where the Apono connector is deployed.
Rancher UI URL (optional)
(Optional) URL of your Rancher UI
This URL must be reachable from all the hosts that you add.
Click Next. The Secret Store section expands.
Click Next. The Get more with Apono section expands.
Define the Get more with Apono settings.
Credential Rotation
(Optional) Number of days after which the database credentials must be rotated
Learn more about the .
User cleanup after access is revoked (in days)
(Optional) Defines the number of days after access has been revoked that the user should be deleted
Learn more about .
Custom Access Details
(Optional) Instructions explaining how to access this integration's resources Upon accessing an integration, a message with these instructions will be displayed to end users in the User Portal. The message may include up to 400 characters. To view the message as it appears to end users, click Preview.
Integration Owner
(Optional) Fallback approver if no is found Follow these steps to define one or several integration owners:
From the Attribute dropdown menu, select User or Group under the relevant identity provider (IdP) platform.
From the Value dropdown menu, select one or multiple users or groups.
NOTE: When Resource Owner is defined, an Integration Owner must be defined.
Click Confirm.
Make any additional edits.
Deploy the code in your Terraform.
Refer to Integration Config Metadata for more details about the schema definition.
Rancher Admin Access
User account with admin permissions to create a new user account
Integration Name
Unique, alphanumeric, user-friendly name used to identify the integration when constructing an access flow
Host
Hostname of the Rancher server
inheritedClusterRoles:
- cluster-owner"access_key": "RANCHER_ACCESS_KEY",
"secret_key": "RANCHER_SECRET_KEY"Resource Owner
(Optional) Group or role responsible for managing access approvals or rejections for the resource Follow these steps to define one or several resource owners:
Enter a Key name. This value is the name of the tag created in your cloud environment.
From the Attribute dropdown menu, select an attribute under the IdP platform to which the key name is associated. Apono will use the value associated with the key (tag) to identify the resource owner. When you update the membership of the group or role in your IdP platform, this change is also reflected in Apono.
NOTE: When this setting is defined, an Integration Owner must also be defined.
Create an integration to manage access to ArgoCD resources
ArgoCD is a Kubernetes-native continuous delivery (CD) tool that implements GitOps practices by using Git repositories as the single source of truth for application state.
Through this integration, Apono helps you discover ArgoCD roles and resources and securely manage just-in-time (JIT) access to them.
The steps to set up Apono in ArgoCD depend on where the Apono Connector is running and what permissions it has. The connector’s location determines whether you need to create a new service account, bind roles, or provide a token secret.
Use the tabs below to follow the instructions that match your environment:
Same cluster (cluster-admin): The connector already has full permissions.
Same cluster (limited permissions): Grant the connector’s existing service account the minimal Role/RoleBinding it needs.
Different cluster: Create a dedicated service account in the ArgoCD cluster and provide its token to Apono.
Follow these steps to set up Apono access in ArgoCD:
Open the argocd-cm ConfigMap in your default editor.
Add email to both the OIDC scopes: requestedScopes and groupsClaim.
You can now Integrate ArgoCD.
You can also use the steps below to integrate with Apono using Terraform.
In step 11, instead of clicking Confirm, follow the Are you integrating with Apono using Terraform? guidance.
Follow these steps to complete the integration:
On the tab, click ArgoCD. The Connect Integration page appears.
Under Discovery, click one or more resource types to sync with Apono.
Click Next. The Apono connector section expands.
From the dropdown menu, select a connector. Choosing a connector links Apono to all the services available on the account where the connector is located.
If the desired connector is not listed, click + Add new connector and follow the instructions for creating a connector (, , , ).
Click Next. The Integration Config section expands.
Define the Integration Config settings.
Click Next. The Get more with Apono section expands.
Define the Get more with Apono settings.
Now that you have completed this integration, you can that grant permission to your ArgoCD resources.
Create an integration to manage access to Grafana resources
Grafana is an open-source observability platform that enables teams to monitor infrastructure, applications, and business metrics through interactive dashboards and alerts.
With this integration, Apono helps you to manage access to Grafana's data sources based on access flow configurations.
You can also use the steps below to integrate with Apono using Terraform.
In step 10, instead of clicking Confirm, follow the Are you integrating with Apono using Terraform? guidance.
Follow these steps to complete the integration:
On the tab, click Grafana. The Connect Integration page appears.
Under Discovery, click Next. The Apono connector section expands.
From the dropdown menu, select a connector. Choosing a connector links Apono to all the services available on the account where the connector is located.
Click Next. The Integration Config section expands.
Define the Integration Config settings.
Click Next. The Get more with Apono section expands.
Define the Get more with Apono settings.
Now that you have completed this integration, you can that grant permission to your Grafana resources.
This allows ArgoCD to map users by email, in addition to groups.
The following example is an edited ConfigMap.
Define your ArgoCD roles.
Restart the ArgoCD API server for the changes to take effect.
Follow these steps to set up Apono access in ArgoCD:
Copy and save the following snippet as apono-argocd-sa.yaml.
At the shell prompt, apply the file to your ArgoCD cluster.
Open the argocd-cm ConfigMap in your default editor.
Add email to both the OIDC scopes: requestedScopes and groupsClaim.
Define your ArgoCD roles.
Restart the ArgoCD API server for the changes to take effect.
Follow these steps to set up Apono access in ArgoCD:
Copy and save the following snippet as apono-argocd-sa.yaml.
At the shell prompt, apply the file to your ArgoCD cluster.
Open the argocd-cm ConfigMap in your default editor.
Add email to both the OIDC scopes: requestedScopes and groupsClaim.
Define your ArgoCD roles.
Restart the ArgoCD API server for the changes to take effect.
Generate the service account token.
Make sure you are using a Kubernetes version ≥1.24.
On earlier versions, you may need to retrieve the token from the service account’s Secret.
with the token from step 7. Use the following key-value pair structure when generating the secret. Be sure to replace #K8_SERVICE_TOKEN with the actual value.
You can also input the token directly into the Apono UI during the integration process.
ArgoCD Namespace
Kubernetes namespace where ArgoCD is installed Default: argocd
Kubernetes Server URL
(Optional) API server endpoint of the Kubernetes cluster hosting ArgoCD
Provide the URL only when connecting to an external Kubernetes API server.
Leave this field blank when Apono’s connector is running in the same cluster.
Kubernetes Certificate Authority
(Optional) Certificate Authority (CA) bundle used to validate the Kubernetes API server certificate
Provide the CA file if connecting to an external cluster with a custom CA.
Leave this field blank when Apono's connector is running in the same cluster.
Click Next. The Secret Store section expands.
(Different cluster) Associate the secret or credentials.
Custom Access Details
(Optional) Instructions explaining how to access this integration's resources
Upon accessing an integration, a message with these instructions will be displayed to end users in the User Portal. The message may include up to 400 characters.
To view the message as it appears to end users, click Preview.
Integration Owner
(Optional) Fallback approver if no is found Follow these steps to define one or several integration owners:
From the Attribute dropdown menu, select User or Group under the relevant identity provider (IdP) platform.
From the Value dropdown menu, select one or multiple users or groups.
NOTE: When Resource Owner is defined, an Integration Owner must be defined.
Resource Owner
(Optional) Group or role responsible for managing access approvals or rejections for the resource Follow these steps to define one or several :
Enter a Key name. This value is the name of the tag created in your cloud environment.
From the Attribute dropdown menu, select an attribute under the IdP platform to which the key name is associated. Apono will use the value associated with the key (tag) to identify the resource owner. When you update the membership of the group or role in your IdP platform, this change is also reflected in Apono.
NOTE: When this setting is defined, an Integration Owner must also be defined.
Click Confirm.
Make any additional edits.
Deploy the code in your Terraform.
Refer to Integration Config Metadata for more details about the schema definition.
Apono connector
On-prem connection serving as a bridge between an ArgoCD instance and Apono:
Kubernetes Command Line Tool (kubectl)
Command-line tool used for communicating with a Kubernetes cluster's control plane
ArgoCD
Instance installed and configured with your Identity Provider (IdP) for authentication
Integration Name
Unique, alphanumeric, user-friendly name used to identify this integration when constructing an access flow
ArgoCD UI URL
Credential Rotation
(Optional) Number of days after which the database credentials must be rotated
Learn more about the Credentials Rotation Policy.
User cleanup after access is revoked (in days)
kubectl edit configmap argocd-cm -n argocdPublic URL of your ArgoCD instance
Example: https://argocd.my-domain.com
(Optional) Defines the number of days after access has been revoked that the user should be deleted
Learn more about .
oidc.config: |
name: Authentik
issuer: https://my-issuer.com
clientID: myclientid
clientSecret: myclientsecret
requestedScopes:
- openid
- profile
- email
- groups
- offline_access
insecureSkipVerify: true
requestedIDTokenClaims:
groups:
essential: true
groupsClaim: [groups, email]
Click Next. The Secret Store section expands.
Resource Owner
(Optional) Group or role responsible for managing access approvals or rejections for the resource Follow these steps to define one or several :
Enter a Key name. This value is the name of the tag created in your cloud environment.
From the Attribute dropdown menu, select an attribute under the IdP platform to which the key name is associated. Apono will use the value associated with the key (tag) to identify the resource owner. When you update the membership of the group or role in your IdP platform, this change is also reflected in Apono.
NOTE: When this setting is defined, an Integration Owner must also be defined.
Click Confirm.
Make any additional edits.
Deploy the code in your Terraform.
Refer to Integration Config Metadata for more details about the schema definition.
Apono connector
On-prem connection serving as a bridge between a MySQL instance and Apono:
Learn how to update an existing , , , or connector.
Grafana Portal URL
Public URL of your Grafana portal
Grafana API key
Randomly generated string used as an alternative to a password when accessing Grafana’s HTTP API
Be sure to copy the key after it has been generated. Create your secret based on your Grafana API key:
"api_key": <GRAFANA_API_KEY>
Integration Name
Unique, alphanumeric, user-friendly name used to identify this integration when constructing an access flow
Grafana Portal URL
Custom Access Details
(Optional) Instructions explaining how to access this integration's resources Upon accessing an integration, a message with these instructions will be displayed to end users in the User Portal. The message may include up to 400 characters. To view the message as it appears to end users, click Preview.
Integration Owner
Public URL of your Grafana portal
Example: https://grafana.company.com
(Optional) Fallback approver if no is found Follow these steps to define one or several integration owners:
From the Attribute dropdown menu, select User or Group under the relevant identity provider (IdP) platform.
From the Value dropdown menu, select one or multiple users or groups.
NOTE: When Resource Owner is defined, an Integration Owner must be defined.
# Example in argocd-rbac-cm
policy.csv: |
p, role:readonly, applications, get, */*, allow
p, role:deployer, applications, sync, */*, allow# Example in an AppProject CRD
roles:
- name: deployer
description: Can sync apps in this project
policies:
- p, proj:team-a:deployer, applications, sync, team-a/*, allowkubectl rollout restart deployment argocd-server -n argocdapiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: apono-argocd-editor
namespace: argocd
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["argocd-rbac-cm"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["argoproj.io"]
resources: ["appprojects"]
verbs: ["get", "list", "watch", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: apono-argocd-editor-binding
namespace: argocd
subjects:
- kind: ServiceAccount
name: <existing-connector-service-account-name>
namespace: argocd
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: apono-argocd-editorkubectl apply -f apono-argocd-sa.yamlkubectl edit configmap argocd-cm -n argocdoidc.config: |
name: Authentik
issuer: https://my-issuer.com
clientID: myclientid
clientSecret: myclientsecret
requestedScopes:
- openid
- profile
- email
- groups
- offline_access
insecureSkipVerify: true
requestedIDTokenClaims:
groups:
essential: true
groupsClaim: [groups, email]
# Example in argocd-rbac-cm
policy.csv: |
p, role:readonly, applications, get, */*, allow
p, role:deployer, applications, sync, */*, allow# Example in an AppProject CRD
roles:
- name: deployer
description: Can sync apps in this project
policies:
- p, proj:team-a:deployer, applications, sync, team-a/*, allowkubectl rollout restart deployment argocd-server -n argocdapiVersion: v1
kind: ServiceAccount
metadata:
name: apono-argocd-sa
namespace: argocd
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: apono-argocd-editor
namespace: argocd
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["argocd-rbac-cm"]
verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["argoproj.io"]
resources: ["appprojects"]
verbs: ["get", "list", "watch", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: apono-argocd-editor-binding
namespace: argocd
subjects:
- kind: ServiceAccount
name: apono-argocd-sa
namespace: argocd
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: apono-argocd-editorkubectl apply -f apono-argocd-sa.yamlkubectl edit configmap argocd-cm -n argocdoidc.config: |
name: Authentik
issuer: https://my-issuer.com
clientID: myclientid
clientSecret: myclientsecret
requestedScopes:
- openid
- profile
- email
- groups
- offline_access
insecureSkipVerify: true
requestedIDTokenClaims:
groups:
essential: true
groupsClaim: [groups, email]
# Example in argocd-rbac-cm
policy.csv: |
p, role:readonly, applications, get, */*, allow
p, role:deployer, applications, sync, */*, allow# Example in an AppProject CRD
roles:
- name: deployer
description: Can sync apps in this project
policies:
- p, proj:team-a:deployer, applications, sync, team-a/*, allowkubectl rollout restart deployment argocd-server -n argocdkubectl -n argocd create token apono-argocd-sa"kubernetes_sa_token":"#K8_SERVICE_TOKEN"