Merge pull request #68 from Conjur-Enterprise/name-change

CNJR-10982: Name Change Updates

Author: akosasi

CHANGELOG.md

@@ -6,7 +6,10 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 
 ## [Unreleased]
 
-## [1.7.5] - 2025-04-01
+## [1.7.5] - 2025-09-09
+
+### Changed
+- Updated documentation to align with Conjur Enterprise name change to Secrets Manager. (CNJR-10982)
 
 ## [1.7.4] - 2025-04-01
 
@@ -368,7 +371,8 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 ### Changed
   - Escape secrets with backslashes before patching in k8s
 
-[Unreleased]: https://github.com/cyberark/secrets-provider-for-k8s/compare/v1.7.4...HEAD
+[Unreleased]: https://github.com/cyberark/secrets-provider-for-k8s/compare/v1.7.5...HEAD
+[1.7.5]: https://github.com/cyberark/secrets-provider-for-k8s/compare/v1.7.4...v1.7.5
 [1.7.4]: https://github.com/cyberark/secrets-provider-for-k8s/compare/v1.7.3...v1.7.4
 [1.7.3]: https://github.com/cyberark/secrets-provider-for-k8s/compare/v1.7.2...v1.7.3
 [1.7.2]: https://github.com/cyberark/secrets-provider-for-k8s/compare/v1.7.1...v1.7.2

CONTRIBUTING.md

@@ -37,21 +37,21 @@ To work in this codebase, you will want to have Go version 1.12+ installed.
 
 ## Documentation
 
-The full documentation for the Cyberark Secrets Provider for Kubernetes can be found [here](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/Latest/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm) for Conjur Enterprise and [here](https://docs.conjur.org/Latest/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm) for Conjur Open Source.
+The full documentation for the Cyberark Secrets Provider for Kubernetes can be found [here](https://docs.cyberark.com/conjur-enterprise/latest/en/content/resources/_topnav/cc_home.htm) for Secrets Manager, Self-Hosted and [here](https://docs.cyberark.com/conjur-open-source/latest/en/content/overview/conjur-oss-suite-overview.html) for Conjur Open Source.
 
 ### Get up and running
 
 Before you can start contributing to the CyberArk Secrets Provider for Kubernetes project, you must:
 
 1. Setup your environment.
 
-    a. For detailed instructions on how to setup a Conjur Enterprise env, see [Conjur Enterprise Setup](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/Latest/en/Content/HomeTilesLPs/LP-Tile1.htm).
+    a. For detailed instructions on how to setup a Secrets Manager, Self-Hosted env, see [Secrets Manager, Self-Hosted Setup](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/Latest/en/Content/HomeTilesLPs/LP-Tile1.htm).
 
     b. For detailed instructions on how to setup a Conjur Open Source env, see [Conjur Open Source Setup](https://docs.conjur.org/Latest/en/Content/HomeTilesLPs/LP-Tile1.htm).
 
 2. Setup the CyberArk Secrets Provider for Kubernetes
 
-    a. For detailed setup instructions for Conjur Enterprise, see [CyberArk Secrets Provider for Kubernetes for Conjur Enterprise](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/Latest/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm).
+    a. For detailed setup instructions for Secrets Manager, Self-Hosted, see [CyberArk Secrets Provider for Kubernetes for Secrets Manager, Self-Hosted](https://docs.cyberark.com/Product-Doc/OnlineHelp/AAM-DAP/Latest/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm).
 
     b. For detailed setup instructions for Conjur Open Source, see [CyberArk Secrets Provider for Kubernetes for Conjur Open Source](https://docs.conjur.org/Latest/en/Content/Integrations/Kubernetes_deployApplicationsConjur-k8s-Secrets.htm).
 
@@ -69,10 +69,10 @@ You can now deploy a local development environment for Kubernetes using [Docker
 
     1. Click on the Kubernetes tab and "Enable Kubernetes"
 
-1. The Secrets Provider for K8s uses the [Kubernetes Conjur deploy](https://github.com/cyberark/kubernetes-conjur-deploy/blob/master/CONTRIBUTING.md) repository to deploy Conjur Enterprise / Conjur Open Source on Kubernetes.
+1. The Secrets Provider for K8s uses the [Kubernetes Conjur deploy](https://github.com/cyberark/kubernetes-conjur-deploy/blob/master/CONTRIBUTING.md) repository to deploy Secrets Manager, Self-Hosted / Conjur Open Source on Kubernetes.
    By default, 2.0 Gib of memory is allocated to Docker on your computer.
 
-   To successfully deploy a Conjur Enterprise cluster (Leader + Followers + Standbys), you will need to increase the memory limit to 6 Gib. To do so, perform the following:
+   To successfully deploy a Secrets Manager, Self-Hosted cluster (Leader + Followers + Standbys), you will need to increase the memory limit to 6 Gib. To do so, perform the following:
 
    1. Navigate to Docker preferences
 
@@ -97,7 +97,7 @@ Run `kubectl config use-context docker-desktop` to switch to a local context. Th
 1. Run `./bin/start --dev`, appending `--oss` or `--dap` according to the environment that needs to be deployed
 
 1. To view the pod(s) that were deployed and the Secrets Provider logs, run `kubectl get pods` and `kubectl logs <pod-name> -c cyberark-secrets-provider-for-k8s` respectively.
-You can also view Conjur Enterprise / Conjur Open Source pod logs by running `kubectl get pods -n local-conjur` and `kubectl logs <conjur-pod-name> -n local-conjur`
+You can also view Secrets Manager, Self-Hosted / Conjur Open Source pod logs by running `kubectl get pods -n local-conjur` and `kubectl logs <conjur-pod-name> -n local-conjur`
 
 1. If a cluster is already locally deployed run `./bin/start --dev --reload` to build your local changes and redeploy them to the local Secrets Provider K8s cluster
 
@@ -170,14 +170,14 @@ To follow [Go testing conventions](https://golang.org/pkg/cmd/go/internal/test/)
 
 Our integration tests can be run against either a GKE / Openshift remote cluster. To do so, run `./bin/start` and add the proper flags.
 
-To deploy Conjur Enterprise / Conjur Open Source, add the `--oss` / `--dap` flags to the above command. By default, the integration tests run Conjur Enterprise, so no flag is required.
+To deploy Secrets Manager, Self-Hosted / Conjur Open Source, add the `--oss` / `--dap` flags to the above command. By default, the integration tests run Secrets Manager, Self-Hosted, so no flag is required.
 To deploy on GKE, add `--gke`. For Openshift, use `--oldest` / `--current` / `--next`. By default, the integration tests run on a GKE cluster,
 so no flag is required.
 
 For example:
 
 - Deploy Conjur Open Source on GKE, run  `./bin/start --oss --gke`
-- Deploy Conjur Enterprise on Openshift, run  `./bin/start --dap --current`
+- Deploy Secrets Manager, Self-Hosted on Openshift, run  `./bin/start --dap --current`
 
 #### Tracing
 

FETCH_ALL.md

@@ -3,7 +3,7 @@
 ## Existing Functionality
 
 In the regular configuration of Secrets Provider, the application developer must
-specify each secret that needs to be retrieved from Conjur. This is done in one
+specify each secret that needs to be retrieved from Secrets Manager. This is done in one
 of two ways, depending on how the secrets are being provided:
 
 ### Kubernetes Secrets
@@ -144,7 +144,7 @@ There are several important things to note about this feature:
 ### Security Implications
 
 - The Fetch All feature should be used with caution, as it can expose more
-  secrets than intended. Ideally, Conjur should be configured to only allow the
+  secrets than intended. Ideally, Secrets Manager should be configured to only allow the
   host to access the secrets that it needs. Additionally, the host should only
   be used for a small unit, such as a single application, and therefore only
   need access to a small number of secrets. If the host has access to a large
@@ -157,7 +157,7 @@ There are several important things to note about this feature:
 ### Performance and Reliability
 
 - Using Fetch All will be slightly slower than specifying each secret
-  individually, as it requires multiple requests to Conjur - first to list all
+  individually, as it requires multiple requests to Secrets Manager - first to list all
   the available secrets, and then to fetch them. In cases where performance is
   critical, it may be better to specify the secrets individually.
 
@@ -179,12 +179,12 @@ There are several important things to note about this feature:
 
 - There is no way to use aliases for secrets when using the Fetch All feature.
   This means that the keys used for the secrets (both in K8s Secrets and P2F)
-  will be the *full path* of the secret in Conjur. At the same time, Kubernetes
+  will be the *full path* of the secret in Secrets Manager. At the same time, Kubernetes
   secrets do not allow keys to contain slashes (`/`) or most other special
   characters. Due to these limitations:
 
   - *In K8s secrets mode:* Any slashes, spaces or other special characters
-    (besides `_`, `-`, and `.`) in the Conjur secret path will be replaced with
+    (besides `_`, `-`, and `.`) in the Secrets Manager secret path will be replaced with
     dots (`.`) in the key names when using K8s Secrets. For example, if the
     secret is stored at `host/my-app/secrets/db-password`, the key in the K8s
     Secret will be `host.my-app.secrets.db-password`.
@@ -199,7 +199,7 @@ There are several important things to note about this feature:
     will be ignored. This will cause non-deterministic behavior in the
     application and must be avoided.
 
-  - *In P2F mode:* The key names will be the full path of the secret in Conjur.
+  - *In P2F mode:* The key names will be the full path of the secret in Secrets Manager.
     For example, if the secret is stored at `host/my-app/secrets/db-password`,
     the key in the P2F file will be `host/my-app/secrets/db-password`.
     This poses no issues for YAML and JSON files, since those formats