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 aide à 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 (parmi : « cyber_ark », « workload », « k8s »)	Oui
`subdomain`	Le sous-domaine de votre entreprise	Oui
`fetch_all_versions`	Indique s'il faut collecter toutes les versions des secrets	Oui
`mode`	Mode d'intégration (parmi : « read », « write », « read/write »)	Non	"read"
`env`	Libellé d'environnement pour catégoriser les secrets (par ex. « production », « staging », « development »)	Non
`owner`	Propriétaire de cette source (un e-mail, généralement d'un employé ou d'une équipe)	Non
`include`	Liste de motifs de chemins à inclure dans la collecte de secrets	Non
`exclude`	Liste de motifs de chemins à exclure de la collecte de secrets	Non

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

Pour l'authentification CyberArk :

Paramètre	Description	Requis
`auth.client_id`	Le client ID pour l'authentification	Oui
`auth.client_secret`	Le client secret pour l'authentification	Oui
`auth.tenant_id`	Le tenant ID	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 s'exécutant dans des clusters Kubernetes, vous pouvez configurer CyberArk Secrets Manager SaaS afin d'utiliser une authentification basée sur JWT. Cela permet à vos workloads Kubernetes de s'authentifier auprès de CyberArk Secrets Manager SaaS via des tokens de service account.

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

Récupérez l'URL de l'issuer OIDC de votre cluster EKS :

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

La sortie sera une URL comme https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED5A3C59576A0175F11F3414644.

L'URI JWKS est l'URL de l'issuer suivie de /keys : https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED5A3C59576A0175F11F3414644/keys

Pour les autres clusters Kubernetes

Pour les clusters qui exposent l'endpoint 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 via l'UI, l'API ou la CLI de CyberArk Secrets Manager SaaS.

Via l'UI 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
Saisissez un nom unique pour l'authentificateur (par ex. 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'issuer 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 policy

Lorsque vous utilisez des fichiers de policy, votre policy 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 ]

Puis 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 le workload branch et l'identité

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

Créer le policy branch (CLI requise)

Si vous utilisez l'UI pour créer des workloads, vous devez d'abord créer le policy branch via la CLI, car cela ne peut pas être fait depuis l'UI.

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

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 le policy branch :

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

Créer l'identité de workload

Après avoir créé le policy branch, vous pouvez créer l'identité de workload via l'UI ou la CLI.

Option A : via l'UI de CyberArk Secrets Manager SaaS

Naviguez vers Workloads dans l'UI de CyberArk Secrets Manager SaaS
Cliquez sur Create workload
Sélectionnez JWT comme méthode d'authentification
Choisissez votre authentificateur JWT (par ex. 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 ex. myspace/jwt-apps)
- Annotations : ajoutez les métadonnées pertinentes
  - kubernetes/namespace : my-namespace
  - kubernetes/service-account : my-service-account

Option B : via une policy CLI (étapes détaillées)

Étape 1 : créer la policy d'hôte de workload

Enregistrez la policy 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 ex. 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 ex. system:serviceaccount:my-namespace:my-service-account)
<service-id> est le nom de votre authentificateur JWT (par ex. k8s-cluster-name)
<jwt-claim-name> est le nom d'un claim JWT (par ex. 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:ggscout-namespace:ggscout-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 policy de 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 policy authn-jwt-grant.yaml :

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

Chargez la policy 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 policy de workload complète avec secrets

Pour une configuration complète incluant secrets et 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 policy complète :

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

Exemple de plusieurs workloads

Pour plusieurs workloads Kubernetes, vous pouvez les créer en 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 du 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 de l'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 service account au format system:serviceaccount:<namespace>:<serviceaccount-name>.
Suivez le moindre privilège : créez des identités d'hôte spécifiques pour chaque workload et n'accordez que les permissions minimales requises.
Correspondance du Workload ID : assurez-vous que le workload ID dans CyberArk Secrets Manager SaaS correspond exactement au format de service account 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 policies en utilisant des groupes, layers et permits.

Méthode 1 : assignation directe de variable

Créez des variables et assignez les privilèges directement à un groupe ou 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 par policy

Pour une meilleure organisation, créez une policy dédiée aux 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 policies de secrets

Après avoir créé vos policies 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

Via l'UI de CyberArk Secrets Manager SaaS

Exemple de policy

Étape 3 : créer le workload branch et l'identité

Créer le policy branch (CLI requise)

Créer l'identité de workload

Option A : via l'UI de CyberArk Secrets Manager SaaS

Option B : via une policy CLI (étapes détaillées)

Exemple de plusieurs workloads

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 : assignation directe de variable

Méthode 2 : organisation des secrets par policy

Charger les policies de secrets

Was this page helpful?

Il manque quelque chose ?

Voir notre feuille de route

S'abonner sur GitHub

Soumettre une demande

Statut de l’API

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​

Via l'UI de CyberArk Secrets Manager SaaS​

Exemple de policy​

Étape 3 : créer le workload branch et l'identité​

Créer le policy branch (CLI requise)​

Créer l'identité de workload​

Option A : via l'UI de CyberArk Secrets Manager SaaS​

Option B : via une policy CLI (étapes détaillées)​

Exemple de plusieurs workloads​

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 : assignation directe de variable​

Méthode 2 : organisation des secrets par policy​

Charger les policies de secrets​

Was this page helpful?

Il manque quelque chose ?

Voir notre feuille de route

S'abonner sur GitHub

Soumettre une demande

Statut de l’API

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

Via l'UI de CyberArk Secrets Manager SaaS

Exemple de policy

Étape 3 : créer le workload branch et l'identité

Créer le policy branch (CLI requise)

Créer l'identité de workload

Option A : via l'UI de CyberArk Secrets Manager SaaS

Option B : via une policy CLI (étapes détaillées)

Exemple de plusieurs workloads

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 : assignation directe de variable

Méthode 2 : organisation des secrets par policy

Charger les policies de secrets