If you want to create multiple components that fetch data from different argoCD instances, you can dynamically set the ArgoCD instance url by adding the following to your app-config.yaml files.
The Argo plugin will fetch the Argo CD instances an app is deployed to and use the backstage-plugin-argo-cd-backend plugin to reach out to each Argo instance based on the mapping mentioned below.
argocd:
username: ${ARGOCD_USERNAME}
password: ${ARGOCD_PASSWORD}
waitCycles: 25
appLocatorMethods:
- type: 'config'
instances:
- name: argoInstance1
url: https://argoInstance1.com
token: ${ARGOCD_AUTH_TOKEN} # optional
- name: argoInstance2
url: https://argoInstance2.com
# dedicated username/password for this instance
username: ${ARGOCD_USERNAME_INSTANCE_2} # optional
password: ${ARGOCD_PASSWORD_INSTANCE_2} # optionalOption 1: Add the required auth tokens to environmental variables, ARGOCD_USERNAME and ARGOCD_PASSWORD inside the argocd object. It will be use as credentials for all instances by default.
Example
argocd:
username: ${ARGOCD_USERNAME}
password: ${ARGOCD_PASSWORD}
appLocatorMethods:
- type: 'config'
instances:
- name: argoInstance1
url: https://argoInstance1.com
- name: argoInstance2
url: https://argoInstance2.comOption 2: Define a username and a password for each instance. It has an higher priority than Option 1.
Example
argocd:
username: ${ARGOCD_USERNAME}
password: ${ARGOCD_PASSWORD}
appLocatorMethods:
- type: 'config'
instances:
- name: argoInstance1
url: https://argoInstance1.com
- name: argoInstance2
url: https://argoInstance2.com
# dedicated username/password for this instance
username: ${ARGOCD_USERNAME_INSTANCE_2}
password: ${ARGOCD_PASSWORD_INSTANCE_2}Option 3: Define a token for each instance. It has an higher priority than Option 1 and Option 2.
Example
argocd:
username: ${ARGOCD_USERNAME}
password: ${ARGOCD_PASSWORD}
appLocatorMethods:
- type: 'config'
instances:
- name: argoInstance1
url: https://argoInstance1.com
token: ${ARGOCD_AUTH_TOKEN} # Token to use to instance 1In order to control what kind of resources are allowed or blocked by default on the created argo projects you can configure a black and/or white list at both the cluster and namespace levels.
Example
argocd:
username: ${ARGOCD_USERNAME}
password: ${ARGOCD_PASSWORD}
projectSettings:
# Sets the allowed resources at the cluster level
clusterResourceWhitelist:
- group: '*'
kind: '*'
# Sets the blocked resources at the cluster level
clusterResourceBlacklist:
- group: '*'
kind: '*'
# Sets the allowed resources at the namespace level
namespaceResourceWhitelist:
- group: '*'
kind: '*'
# Sets the blocked resources at the namespace level
namespaceResourceBlacklist:
- group: '*'
kind: '*'For example to block specific resources
argocd:
username: ${ARGOCD_USERNAME}
password: ${ARGOCD_PASSWORD}
projectSettings:
# block cluster roles and bindings
clusterResourceBlacklist:
- group: 'rbac.authorization.k8s.io'
kind: 'ClusterRole'
- group: 'rbac.authorization.k8s.io'
kind: 'ClusterRoleBinding'
# Blocks the creation of cron jobs
namespaceResourceBlacklist:
- group: 'batch'
kind: 'CronJob'Similarly you can instead allow only a certain set of resources
argocd:
username: ${ARGOCD_USERNAME}
password: ${ARGOCD_PASSWORD}
projectSettings:
clusterResourceBlacklist:
- group: '*'
kind: '*'
# Only the listed resources will be allowed
namespaceResourceWhitelist:
- group: 'apps'
kind: 'Deployment'
- group: ''
kind: 'Service'
- group: 'networking.k8s.io'
kind: 'Ingress'Between the Argo CD project delete and application delete there is a loop created to check for the deletion of the application before the deletion of a project can occur. Between each check there is a 3 second timer. The number of cycles to wait is an optional configuration value as shown above as waitCycles. If waitCycles is set to 25, the total time the loop can last before erroring out is 75 seconds.
Setting permissions for the Argo CD user account can reduce the scope, but also reduce the functionality of the backend. If you choose to scope the permissions for read-only get actions will work such as the catalog plugin but creating, deleting, and resyncing applications will not be available. The error handling has been designed to alert the users when the proper permissions are not in place.
By default the Argo CD Server will generate a self signed certificate. For testing purposes you can use the below to allow http traffic. This should not be used for production. The backend will validate certificates and a self signed certificate will not work properly, which is why for testing enabling http might be preferred.
Once you have installed Argo CD, the deployment of argocd-server can be patched to be insecure using the below command,
kubectl patch deployment argocd-server --type "json" -p '[{"op":"add","path":"/spec/template/spec/containers/0/command/-","value":"--insecure"}]'Or using Helm you can install Argo CD and be insecure by default.
helm upgrade --install argocd argo/argo-cd \
--version 3.33.5 \
--set 'server.extraArgs={--insecure}'