Intégration CyberArk Secrets Manager SaaS

ggscout prend en charge l'intégration avec CyberArk Secrets Manager SaaS pour collecter et surveiller vos secrets. Ce guide vous aidera à mettre en place et configurer l'intégration.

Fonctionnalités prises en charge

Collecte de plusieurs versions de secrets
Authentification CyberArk
Configuration spécifique au tenant
Prise en charge des sous-domaines

Configuration

Le tableau suivant liste les options de configuration disponibles pour ggscout lors de l'intégration avec CyberArk Secrets Manager SaaS :

Paramètre	Description	Requis	Valeur par défaut
`type`	Doit être défini sur `"cyberarksaas"`	Oui
`auth.auth_mode`	Mode d'authentification (l'un de : "cyber_ark", "workload", "k8s")	Oui
`subdomain`	Le sous-domaine de votre entreprise	Oui
`fetch_all_versions`	Collecter ou non toutes les versions des secrets	Oui
`mode`	Mode d'intégration (l'un de : "read", "write", "read/write")	Non	"read"
`env`	Environnement par défaut des secrets de cette source. GitGuardian déduit un environnement par secret et se rabat sur cette valeur	Non
`owner`	Propriétaire de cette source (un e-mail, généralement celui d'un employé ou d'une équipe)	Non
`include`	Liste de motifs de chemins à inclure dans la collecte des secrets	Non
`exclude`	Liste de motifs de chemins à exclure de la collecte des secrets	Non

GitGuardian déduit l'environnement de chaque secret d'abord à partir du chemin de sa branche de politique, puis à partir de ses annotations telles que env ou environment, et n'utilise le env au niveau de la source que lorsqu'aucun des deux ne le nomme.

Avec des paramètres supplémentaires selon le mode d'authentification choisi :

Pour l'authentification CyberArk :

Paramètre	Description	Requis
`auth.client_id`	L'identifiant client pour l'authentification	Oui
`auth.client_secret`	Le secret client pour l'authentification	Oui
`auth.tenant_id`	L'identifiant du tenant	Oui

Pour l'authentification Workload :

Paramètre	Description	Requis	Valeur par défaut
`auth.api_key`	Votre clé API Conjur	Oui
`auth.login`	Votre login Conjur	Oui

Pour l'authentification Kubernetes :

Paramètre	Description	Requis	Valeur par défaut
`auth.service_id`	L'ID de votre authentificateur JWT dans CyberArk Secrets Manager SaaS	Oui

Authentification

ggscout prend en charge plusieurs méthodes d'authentification pour CyberArk Secrets Manager SaaS :

Authentification CyberArk

[sources.cyberarksaas]
type = "cyberarksaas"
auth.auth_mode = "cyber_ark"
auth.client_id = "${CYBERARK_CLIENT_ID}"
auth.client_secret = "${CYBERARK_CLIENT_SECRET}"
auth.tenant_id = "${CYBERARK_TENANT_ID}"
cyberarksaas_url = "${CYBERARK_SAAS_URL}"
subdomain = "my-company"
fetch_all_versions = true
mode = "read"
env = "production"
owner = "devops-team@example.com"

[[sources.cyberarksaas.include]]
resource_ids = ["app/*", "database/*", "api-key"]

[[sources.cyberarksaas.exclude]]
resource_ids = ["test/*", "temp/*", "old-secret"]

Authentification Workload

[sources.cyberarksaas]
type = "cyberarksaas"
auth.auth_mode = "workload"
api_key = "${CONJUR_API_KEY}"
login = "${CONJUR_LOGIN}"
subdomain = "my-company"
fetch_all_versions = true
mode = "read"
env = "production"
owner = "devops-team@example.com"

[[sources.cyberarksaas.include]]
resource_ids = ["app/*", "database/*", "api-key"]

[[sources.cyberarksaas.exclude]]
resource_ids = ["test/*", "temp/*", "old-secret"]

Authentification Kubernetes

[sources.cyberarksaas]
type = "cyberarksaas"
auth.auth_mode = "k8s"
auth.service_id = "k8s-cluster-name"
subdomain = "my-company"
fetch_all_versions = true
mode = "read"
env = "production"
owner = "devops-team@example.com"

[[sources.cyberarksaas.include]]
resource_ids = ["app/*", "database/*", "api-key"]

[[sources.cyberarksaas.exclude]]
resource_ids = ["test/*", "temp/*", "old-secret"]

Instructions de configuration détaillées

Pour les applications exécutées dans des clusters Kubernetes, vous pouvez configurer CyberArk Secrets Manager SaaS pour utiliser l'authentification basée sur JWT. Cela permet à vos workloads Kubernetes de s'authentifier auprès de CyberArk Secrets Manager SaaS à l'aide de tokens de compte de service.

Prérequis

Une instance CyberArk Secrets Manager SaaS en cours d'exécution
Un cluster Kubernetes en cours d'exécution
La CLI kubectl installée et configurée

Étape 1 : Récupérer la configuration OIDC de Kubernetes

Pour AWS EKS

Obtenez l'URL de l'émetteur OIDC pour votre cluster EKS :

aws eks describe-cluster --name <YOUR_EKS_CLUSTER_NAME> --query "cluster.identity.oidc.issuer" --output text

Le résultat sera une URL comme https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED5A3C59576A0175F11F3414644.

L'URI JWKS est l'URL de l'émetteur avec /keys ajouté : https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED5A3C59576A0175F11F3414644/keys

Pour les autres clusters Kubernetes

Pour les clusters qui exposent le point d'accès de découverte OIDC :

# Get the OIDC issuer URL
kubectl get --raw /.well-known/openid-configuration | jq -r '.issuer'

# Get the public keys (JWKS)
kubectl get --raw /openid/v1/jwks

Étape 2 : Configurer l'authentificateur JWT dans CyberArk Secrets Manager SaaS

Vous pouvez créer l'authentificateur JWT à l'aide de l'interface, de l'API ou de la CLI de CyberArk Secrets Manager SaaS.

À l'aide de l'interface de CyberArk Secrets Manager SaaS

Naviguez vers la page Authenticators dans CyberArk Secrets Manager SaaS
Cliquez sur Create authenticator
Sélectionnez JWT comme type d'authentificateur
Entrez un nom unique pour l'authentificateur (par exemple, k8s-cluster-name)
Configurez les variables suivantes :

Variable	Description	Requis	Exemple de valeur
`jwks-uri`	L'URI JWKS de votre cluster Kubernetes	Oui (ou utilisez `public-keys`)	`https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLE/keys`
`public-keys`	Contenu JWKS sous forme de chaîne JSON	Oui (ou utilisez `jwks-uri`)	À utiliser pour les clusters locaux/privés
`issuer`	L'URL de l'émetteur OIDC	Oui	`https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLE`
`token-app-property`	Claim JWT pour l'identité de l'application	Oui	`sub`
`audience`	Audience attendue pour le JWT	Recommandé	`cyberark`

Exemple de politique

Lorsque vous utilisez des fichiers de politique, votre politique d'authentificateur JWT devrait ressembler à ceci :

- !policy
  id: conjur/authn-jwt/k8s-cluster-name
  body:
  - !webservice
    annotations:
      description: JWT authenticator for Kubernetes cluster

  - !variable
    id: jwks-uri

  - !variable
    id: issuer

  - !variable
    id: token-app-property

  - !variable
    id: audience

  - !group users

  - !host-factory
    id: host-factory
    layers: [ !layer users ]

Ensuite, renseignez les variables :

# Set the JWKS URI
conjur variable set -i conjur/authn-jwt/k8s-cluster-name/jwks-uri -v "https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLE/keys"

# Set the issuer
conjur variable set -i conjur/authn-jwt/k8s-cluster-name/issuer -v "https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLE"

# Set the token app property (IMPORTANT: Use 'sub' for Kubernetes)
conjur variable set -i conjur/authn-jwt/k8s-cluster-name/token-app-property -v "sub"

# Set the audience
conjur variable set -i conjur/authn-jwt/k8s-cluster-name/audience -v "conjur"

Étape 3 : Créer la branche et l'identité du workload

Avant de créer des workloads dans CyberArk Secrets Manager SaaS, vous devez mettre en place la structure de politique et les identités de workload.

Créer la branche de politique (CLI requise)

Si vous utilisez l'interface pour créer des workloads, vous devez d'abord créer la branche de politique à l'aide de la CLI, car cela ne peut pas être fait via l'interface.

Connectez-vous à la CLI Conjur :
```
conjur login
```
Créez la politique de branche de workload :

Enregistrez ce qui suit sous workload-branch.yaml :
```
- !policy
  id: <policy-id>
```
Où <policy-id> est le nom de votre branche (par exemple, myspace/jwt-apps ou k8s-apps).

Chargez la branche de politique :

conjur policy load -f workload-branch.yaml -b data

Créer l'identité du workload

Après avoir créé la branche de politique, vous pouvez créer l'identité du workload à l'aide de l'interface ou de la CLI.

Option A : À l'aide de l'interface de CyberArk Secrets Manager SaaS

Naviguez vers Workloads dans l'interface de CyberArk Secrets Manager SaaS
Cliquez sur Create workload
Sélectionnez JWT comme méthode d'authentification
Choisissez votre authentificateur JWT (par exemple, k8s-cluster-name)
Configurez le workload :
- Workload ID : system:serviceaccount:my-namespace:my-service-account
- Policy Branch : La branche que vous avez créée (par exemple, myspace/jwt-apps)
- Annotations : Ajoutez les métadonnées pertinentes
  - kubernetes/namespace : my-namespace
  - kubernetes/service-account : my-service-account

Option B : À l'aide de la politique CLI (étapes détaillées)

Étape 1 : Créer la politique d'hôte du workload

Enregistrez la politique suivante dans un fichier nommé authn-jwt-hosts.yaml :

- !policy
  id: <policy-id>
  body:
    - !group
    - !host
      id: <host-id>
      annotations:
        authn-jwt/<service-id>/<jwt-claim-name>: <jwt-claim-value>

    - !grant
      role: !group
      member: !host

Où :

<policy-id> est le nom de la branche (par exemple, myspace/jwt-apps ou k8s-apps)
<host-id> est le nom du workload. Pour l'authentification JWT Kubernetes utilisant token-app-property, cela doit être la valeur du claim JWT (par exemple, system:serviceaccount:my-namespace:my-service-account)
<service-id> est le nom de votre authentificateur JWT (par exemple, k8s-cluster-name)
<jwt-claim-name> est le nom d'un claim JWT (par exemple, sub, namespace, etc.)
<jwt-claim-value> est la valeur du claim JWT spécifié

Pour les workloads Kubernetes, voici un exemple concret utilisant le claim sub :

- !policy
  id: k8s-apps
  body:
    - !group
    - !host
      id: system:serviceaccount:my-namespace:my-service-account
      annotations:
        kubernetes/namespace: ggscout-namespace
        kubernetes/service-account: ggscout-service-account
        workload/type: ggscout

    - !grant
      role: !group
      member: !host

Étape 2 : Charger la politique du workload

conjur policy load -f authn-jwt-hosts.yaml -b data

Étape 3 : Accorder les permissions du workload à l'authentificateur JWT

Créez un fichier de politique authn-jwt-grant.yaml :

- !grant
  role: !group conjur/authn-jwt/k8s-cluster-name/users
  member: !group /data/k8s-apps

Chargez la politique dans la branche de l'authentificateur JWT :

conjur policy load -f authn-jwt-grant.yaml -b conjur/authn-jwt/k8s-cluster-name

Étape 4 : Créer une politique de workload complète avec des secrets

Pour une configuration complète incluant les secrets et les permissions, créez k8s-workload-complete.yaml :

- !policy
  id: k8s-apps
  body:
  # Create the workload host with proper annotations
  - !host
    id: system:serviceaccount:ggscout-namespace:ggscout-service-account
    annotations:
      authn-jwt/k8s-cluster-name/sub: system:serviceaccount:ggscout-namespace:ggscout-service-account
      kubernetes/namespace: ggscout-namespace
      kubernetes/service-account: ggscout-service-account
      description: "ggscout service account for Kubernetes cluster authentication"

  # Create secrets that this workload can access
  - !variable
    id: database/password

  - !variable
    id: api/token

  # Create a group for this workload's permissions
  - !group
    id: ggscout-consumers

  # Grant the workload access to the consumer group
  - !grant
    role: !group ggscout-consumers
    member: !host system:serviceaccount:ggscout-namespace:ggscout-service-account

  # Grant read permissions to secrets
  - !permit
    role: !group ggscout-consumers
    privilege: [ read, execute ]
    resource: !variable database/password

  - !permit
    role: !group ggscout-consumers
    privilege: [ read, execute ]
    resource: !variable api/token

Chargez la politique complète :

conjur policy load -f k8s-workload-complete.yaml -b data

Exemple de workloads multiples

Pour plusieurs workloads Kubernetes, vous pouvez les créer par lot :

- !policy
  id: myspace/jwt-apps
  body:
  # ggscout workload
  - !host
    id: system:serviceaccount:ggscout-namespace:ggscout-service-account
    annotations:
      kubernetes/namespace: ggscout-namespace
      kubernetes/service-account: ggscout-service-account
      workload/type: ggscout

  # Application workload
  - !host
    id: system:serviceaccount:app-namespace:app-service-account
    annotations:
      kubernetes/namespace: app-namespace
      kubernetes/service-account: app-service-account
      workload/type: application

  # Grant authentication permissions to both
  - !grant
    role: !group conjur/authn-jwt/k8s-cluster-name/users
    members:
      - !host system:serviceaccount:ggscout-namespace:ggscout-service-account
      - !host system:serviceaccount:app-namespace:app-service-account

Conventions de nommage des workloads

Pour les workloads Kubernetes utilisant l'authentification JWT, suivez ces conventions de nommage :

Format de Host ID : system:serviceaccount:<namespace>:<service-account-name>
Policy Branch : Utilisez des regroupements logiques comme k8s-apps, <environment>/k8s, ou <team>/jwt-workloads
Annotations : Incluez des métadonnées pour une meilleure organisation :
- kubernetes/namespace
- kubernetes/service-account
- environment (dev, staging, prod)
- team ou application

Étape 4 : Configurer ggscout pour l'authentification JWT

Ajoutez la configuration d'authentification JWT à votre ggscout.toml :

[sources.cyberarksaas-k8s]
type = "cyberarksaas"
auth.auth_mode = "k8s"
auth.service_id = "k8s-cluster-name"
subdomain = "my-company"
fetch_all_versions = true
mode = "read"
owner = "devops-team@example.com"

Notes importantes

Utilisez toujours sub comme token-app-property : Pour les workloads Kubernetes, le claim sub (subject) contient l'identité du compte de service au format system:serviceaccount:<namespace>:<serviceaccount-name>.
Appliquez le moindre privilège : Créez des identités d'hôte spécifiques pour chaque workload et accordez uniquement les permissions minimales requises.
Correspondance du Workload ID : Assurez-vous que le workload ID dans CyberArk Secrets Manager SaaS correspond exactement au format du compte de service Kubernetes : system:serviceaccount:<namespace>:<service-account-name>.

Étape 6 : Accorder l'accès aux variables/secrets

Après avoir créé votre identité de workload, vous devez lui accorder l'accès aux secrets spécifiques dont elle a besoin. Cela se fait via le système de politique à l'aide de groupes, de layers et d'instructions permit.

Méthode 1 : Affectation directe de variables

Créez des variables et attribuez les privilèges directement à un groupe ou un layer :

- !policy
  id: ggscout-secrets
  body:
    # Define the variables/secrets
    - &variables
      - !variable
        id: db-password
        kind: password

      - !variable
        id: api-token
        kind: API token

      - !variable
        id: ssl/private_key
        kind: SSL private key
        mime_type: application/x-pem-file

    # Create a layer for workloads that need these secrets
    - !layer app

    # Grant access to the variables
    - !permit
      role: !layer app
      privileges: [read, execute]
      resources: *variables

    # Add your workload to the layer
    - !grant
      role: !layer app
      member: !host /data/k8s-apps/system:serviceaccount:ggscout-namespace:ggscout-service-account

Méthode 2 : Organisation des secrets basée sur les politiques

Pour une meilleure organisation, créez une politique dédiée pour les secrets de votre application :

- !policy
  id: ggscout-app-secrets
  owner: !group devops
  annotations:
    description: This policy contains secrets for ggscout application

  body:
    # Define secret variables using YAML anchor
    - &app-secrets
      - !variable
        id: database/password
      - !variable
        id: database/url
      - !variable
        id: database/username
      - !variable
        id: external-api/token
      - !variable
        id: encryption/key

    # Create a group for consumers of these secrets
    - !group consumers

    # Grant read and execute permissions to the consumer group
    - !permit
      role: !group consumers
      privileges: [ read, execute ]
      resources: *app-secrets

    # Add your ggscout workload to the consumers group
    - !grant
      role: !group consumers
      member: !host /data/k8s-apps/system:serviceaccount:ggscout-namespace:ggscout-service-account

Charger les politiques de secrets

Après avoir créé vos politiques de secrets, chargez-les dans CyberArk Secrets Manager SaaS :

# Load the policy
conjur policy load -f ggscout-secrets.yaml -b data

# Set the secret values (example)
conjur variable set -i ggscout-secrets/db-password -v "your-secure-password"
conjur variable set -i ggscout-secrets/api-token -v "your-api-token"

Intégration CyberArk Secrets Manager SaaS

Fonctionnalités prises en charge

Configuration

Authentification

Authentification CyberArk

Authentification Workload

Authentification Kubernetes

Instructions de configuration détaillées

Prérequis

Étape 1 : Récupérer la configuration OIDC de Kubernetes

Pour AWS EKS

Pour les autres clusters Kubernetes

Étape 2 : Configurer l'authentificateur JWT dans CyberArk Secrets Manager SaaS

À l'aide de l'interface de CyberArk Secrets Manager SaaS

Exemple de politique

Étape 3 : Créer la branche et l'identité du workload

Créer la branche de politique (CLI requise)

Créer l'identité du workload

Option A : À l'aide de l'interface de CyberArk Secrets Manager SaaS

Option B : À l'aide de la politique CLI (étapes détaillées)

Exemple de workloads multiples

Conventions de nommage des workloads

Étape 4 : Configurer ggscout pour l'authentification JWT

Notes importantes

Étape 6 : Accorder l'accès aux variables/secrets

Méthode 1 : Affectation directe de variables

Méthode 2 : Organisation des secrets basée sur les politiques

Charger les politiques de secrets

Was this page helpful?

Il manque quelque chose ?

Fonctionnalités prises en charge​

Configuration​

Authentification​

Authentification CyberArk​

Authentification Workload​

Authentification Kubernetes​

Instructions de configuration détaillées​

Prérequis​

Étape 1 : Récupérer la configuration OIDC de Kubernetes​

Pour AWS EKS​

Pour les autres clusters Kubernetes​

Étape 2 : Configurer l'authentificateur JWT dans CyberArk Secrets Manager SaaS​

À l'aide de l'interface de CyberArk Secrets Manager SaaS​

Exemple de politique​

Étape 3 : Créer la branche et l'identité du workload​

Créer la branche de politique (CLI requise)​

Créer l'identité du workload​

Option A : À l'aide de l'interface de CyberArk Secrets Manager SaaS​

Option B : À l'aide de la politique CLI (étapes détaillées)​

Exemple de workloads multiples​

Conventions de nommage des workloads​

Étape 4 : Configurer ggscout pour l'authentification JWT​

Notes importantes​

Étape 6 : Accorder l'accès aux variables/secrets​

Méthode 1 : Affectation directe de variables​

Méthode 2 : Organisation des secrets basée sur les politiques​

Charger les politiques de secrets​

Was this page helpful?

Il manque quelque chose ?

Abonnez-vous à notre newsletter

Fonctionnalités prises en charge

Configuration

Authentification

Authentification CyberArk

Authentification Workload

Authentification Kubernetes

Instructions de configuration détaillées

Prérequis

Étape 1 : Récupérer la configuration OIDC de Kubernetes

Pour AWS EKS

Pour les autres clusters Kubernetes

Étape 2 : Configurer l'authentificateur JWT dans CyberArk Secrets Manager SaaS

À l'aide de l'interface de CyberArk Secrets Manager SaaS

Exemple de politique

Étape 3 : Créer la branche et l'identité du workload

Créer la branche de politique (CLI requise)

Créer l'identité du workload

Option A : À l'aide de l'interface de CyberArk Secrets Manager SaaS

Option B : À l'aide de la politique CLI (étapes détaillées)

Exemple de workloads multiples

Conventions de nommage des workloads

Étape 4 : Configurer ggscout pour l'authentification JWT

Notes importantes

Étape 6 : Accorder l'accès aux variables/secrets

Méthode 1 : Affectation directe de variables

Méthode 2 : Organisation des secrets basée sur les politiques

Charger les politiques de secrets