Update deployment steps to use the new Helm chart

README.md

@@ -23,21 +23,17 @@ A quick start to deploy a sidecar to Kubernetes using Helm!
 #### Quick Start
 
 * Save the code below in a `values.yaml` file.
-    * Fill the parameters `controlPlane.host`, `sidecarId`, `forwardProxy.clientId`, 
-    and `forwardProxy.clientSecret` with the information from the `Cyral Templates` option
+    * Fill the parameters `cyral.controlPlane`, `cyral.sidecarId`, `cyral.credentials.clientId`, 
+    and `cyral.credentials.clientSecret` with the information from the `Cyral Templates` option
     in the `Deployment` tab of your sidecar details.
 
 ```yaml
-controlPlane:
-  host: ""
-
-sidecarId: ""
-
-forwardProxy:
-  clientId: ""
-  clientSecret: ""
-  secretName: sidecar-secret
-  secretKeyName: credentials.json
+cyral:
+  controlPlane: ""
+  sidecarId: ""
+  credentials:
+    clientId: ""
+    clientSecret: ""
 ​
 service:
   enabled: true
@@ -75,10 +71,10 @@ service:
     * `<VERSION>`: the version of your sidecar.
 
 ```bash
-helm repo add cyral https://charts.cyral.com
-helm upgrade -i <SIDECAR_RELEASE_NAME> cyral/cyral-sidecar \
-  --namespace <SIDECAR_NAMESPACE> -f values.yaml \
+helm upgrade -i <SIDECAR_RELEASE_NAME> \
   --create-namespace \
+  --namespace <SIDECAR_NAMESPACE> -f values.yaml \
+  oci://public.ecr.aws/cyral/helm/sidecar \
   --version <VERSION>
 ```
 
@@ -94,21 +90,17 @@ as part of the [repository configuration](https://cyral.com/docs/manage-reposito
 
 
 * Save the code below in a `values.yaml` file.
-    * Fill the parameters `controlPlane.host`, `sidecarId`, `forwardProxy.clientId`, 
-    and `forwardProxy.clientSecret` with the information from the `Cyral Templates` option
+    * Fill the parameters `cyral.controlPlane`, `cyral.sidecarId`, `cyral.credentials.clientId`, 
+    and `cyral.credentials.clientSecret` with the information from the `Cyral Templates` option
     in the `Deployment` tab of your sidecar details.
 
 ```yaml
-controlPlane:
-  host: ""
-
-sidecarId: ""
-
-forwardProxy:
-  clientId: ""
-  clientSecret: ""
-  secretName: sidecar-secret
-  secretKeyName: credentials.json
+cyral:
+  controlPlane: ""
+  sidecarId: ""
+  credentials:
+    clientId: ""
+    clientSecret: ""
 
 # Sets the node and inter-pod affinities so pods won't run
 # in the same node.
@@ -157,9 +149,9 @@ service:
     * `<VERSION>`: the version of your sidecar.
 
 ```bash
-helm repo add cyral https://charts.cyral.com
-helm upgrade -i <RELEASE_NAME> cyral/cyral-sidecar /
-  --namespace <SIDECAR_NAMESPACE> -f values.yaml /
+helm upgrade -i <RELEASE_NAME> \
+  --namespace <SIDECAR_NAMESPACE> -f values.yaml \
+  oci://public.ecr.aws/cyral/helm/sidecar \
   --version <VERSION> --create-namespace
 ```
 
@@ -194,9 +186,9 @@ Use the following procedure to upgrade your sidecar:
     * `<VERSION>`: the version the sidecar should be upgraded to.
 
 ```bash
-helm upgrade -i <SIDECAR_NAMESPACE> cyral-sidecar /
-  --namespace <SIDECAR_NAMESPACE> -f values.yaml /
-  --repo https://charts.cyral.com /
+helm upgrade -i <RELEASE_NAME> \
+  --namespace <SIDECAR_NAMESPACE> -f values.yaml \
+  oci://public.ecr.aws/cyral/helm/sidecar \
   --version <VERSION>
 ```
 

docs/certificates.md

@@ -97,12 +97,13 @@ Suppose you created the secrets `my-tls-secret` and `my-ca-secret`, then
 provide the following to your values file:
 
 ```yaml
-certificateManager:
-  certificates:
-    tls:
-      existingSecret: "my-tls-secret"
-    ca:
-      existingSecret: "my-ca-secret"
+cyral:
+  sidecar:
+    certificates:
+      tls:
+        existingSecret: "my-tls-secret"
+      ca:
+        existingSecret: "my-ca-secret"
 ```
 
 The choice between providing a `tls`, a `ca` secret or *both* will depend on the repositories

docs/database-accounts/environment-variables.md

@@ -66,13 +66,12 @@ With the secret created, you need to add an environment variable to the `authent
 field of the `values.yaml` file used to create the sidecar.
 
 ```yaml
-authenticator:
-  extraEnvs:
-  - name: CYRAL_DBSECRETS_<env-var-configured-in-the-control-plane>
-    valueFrom:
-      secretKeyRef:
-        name: $SECRET_NAME
-        key: credentials
+extraEnvs:
+- name: CYRAL_DBSECRETS_<env-var-configured-in-the-control-plane>
+  valueFrom:
+    secretKeyRef:
+      name: $SECRET_NAME
+      key: credentials
 ```
 
 ## Multiple credentials in a single secret
@@ -132,17 +131,16 @@ kubectl apply -f secret.yaml
 To add them all, just add multiple environment variables in the `values.yaml` file.
 
 ```yaml
-authenticator:
-  extraEnvs:
-  - name: CYRAL_DBSECRETS_<repo1 env var>
-    valueFrom:
-      secretKeyRef:
-        name: $SECRET_NAME
-        key: repo1
-  - name: CYRAL_DBSECRETS_<repo2 env var>
-    valueFrom:
-      secretKeyRef:
-        name: $SECRET_NAME
-        key: repo2
+extraEnvs:
+- name: CYRAL_DBSECRETS_<repo1 env var>
+  valueFrom:
+    secretKeyRef:
+      name: $SECRET_NAME
+      key: repo1
+- name: CYRAL_DBSECRETS_<repo2 env var>
+  valueFrom:
+    secretKeyRef:
+      name: $SECRET_NAME
+      key: repo2
   ...
 ```

docs/metrics.md

@@ -7,16 +7,19 @@ on the `Prometheus` configuration for your `Kubernetes` cluster. You can
 set the metrics port by adding the following to your `values.yaml` file:
 
 ```yaml
-metrics:
-  port: 9000 # this is the default value
+containerPorts:
+  metrics: 9000 # this is the default value
 ```
 
-By default, this port will be exposed on the `Service` object created by the `helm` chart.
-To disable its exposure, you can add the following to your `values.yaml` file:
+By default, this port will not be exposed on the `Service` object created by the `helm` chart.
+To enable its exposure, you can add the following to your `values.yaml` file:
 
 ```yaml
-metrics:
-  expose: false
+service:
+  ports:
+    metrics: 9000
+  targetPort:
+    metrics: metrics
 ```
 
 ## Prometheus configuration

docs/port-configuration.md

@@ -3,56 +3,62 @@
 A single Cyral sidecar cluster usually monitors and protects many
 repositories of different types. To make it easy for data users to
 connect to these repositories using the port numbers they're
-accustomed to, the sidecar cluster exposes multiple ports, which
-are neatly organized in each repo's section of the provided values
-file.
+accustomed to, the sidecar cluster exposes multiple ports.
+You can restrict or increase the set of exposed ports by changing
+the exposed ports in the `values.yaml` file.
 
-You can restrict or increase the set of exposed ports by either changing
-the exposed ports for each repository or by overriding all ports on the main
-service configuration of the `values.yaml` file.
+## Declaring container ports
 
-## Changing a single repository exposed ports
-
-On the `values.yaml` file, you can disable a specific repository, which will make its
-defined ports not get exposed in the main service. For example, by default,
-the `mysql` section of the `values.yaml` file contains this definition:
+On the `values.yaml` file, you can find different parameters related
+to ports exposure. The `containerPorts` object specifies which ports
+the container will listen on. It has a map of `<port-name>: <port-number>`,
+where `<port-name>` is an arbitrary name for the port and `<port-number>`
+is an integer to the TCP port. These are the same port numbers used to bind
+data repositories on the Control Plane.
 
 ```yaml
-mysql:
-  enabled: true
-  ...
-  ports:
-    ...
-    # ports that are added to the sidecar service
-    sidecar:
-      - 3306
-      - 3307
-      - 3308
- ...
+containerPorts:
+  mysql: 3306
+  pg: 5432
+  mongodb0: 27017
+  mongodb1: 27018
+  mongodb2: 27019
 ```
 
-This means that the ports `3306`, `3307` and `3308` will be exposed in the
-sidecar service. To increase or decrease the ports exposed for `mysql`, you can
-add or remove ports from the `mysql.sidecar.ports` section of the `values.yaml` file.
-This is analogous for all repositories, that is, you can change the `<repo>.sidecar.ports`
-section to add or remove specific ports from the exposed list.
+The above example declares some port names (`mysql`, `pg`, `mongodb0`, `mongodb1`,
+and `mongodb2`) and their corresponding port numbers. We can refer to these port
+names later on to expose them through a Kubernetes service.
+
+## Exposing container ports
 
-**NOTE:** If a repository is disabled, that is, the `<repo>.enabled` key is set to `false`,
-none of its ports will be exposed in the service.
+To expose container ports to external traffic or to other pods within the cluster, you need to set
+service ports. The `service` object defines `ports` and `targetPorts`. The `ports` property specifies
+the ports the Service will expose, while `targetPort`  maps the Service ports to the container's
+`containerPorts` declared previously.
 
-## Overriding all exposed ports
+In `service.ports`, you define a map of `<port-name>: <port-number>` where the Kubernetes service
+will listen on. Then, you can use `service.targetPorts` to map service ports to container ports
+in the format `<service-port-name>: <container-port-name>`. For instance, assuming you defined a
+container port as `mysql: 3306` and a service port as `mysql: 3306`, you can set `mysql: mysql`
+in `targetPorts` to create a link between them.
 
-If you only need to expose a few ports and don't want to go through the trouble of
-changing all repository ports, you can use the `service.ports` section of the
-`values.yaml` file, which will make the chart ignore repo-specific port definitions
-and only expose the ports defined in that section.
+Following is an example of how to set service ports.
 
 ```yaml
 service:
   ...
   ports:
-    - 5432
-    - 3306
+    mysql: 3306
+    pg: 5432
+    mongodb0: 27017
+    mongodb1: 27018
+    mongodb2: 27019
+  targetPort:
+    mysql: mysql
+    pg: pg
+    mongodb0: mongodb0
+    mongodb1: mongodb1
+    mongodb2: mongodb2
 ```
 
-The above example makes no port but `3306` and `5432` be exposed on the service.
+The above example expose ports `3306`, `5432`, `27017`, `27018`, and `27019` on the service.

docs/pre-existing-sa.md

@@ -50,11 +50,10 @@ accounts. Below, we explain how to do this.
 
 3. **Modify the values.yaml file**: The downloaded `values.yaml` files
    need to be modified to use the above-created service account.
-   Note that `rbac.create` must be set to false:
+   Note that `serviceAccount.create` must be set to false:
 
    ```yaml
-    rbac:
-        serviceAccount:
-            name: $SIDECAR_SA
+    serviceAccount:
+        name: $SIDECAR_SA
         create: false
    ```

docs/public-load-balancer.md

@@ -14,9 +14,10 @@ By default, EKS provisions an internal facing load balancer for a `LoadBalancer`
 you need to add the following annotations on the `service.annotations` field of the values file:
 
 ```yaml
-annotations:
-service.beta.kubernetes.io/aws-load-balancer-type: "external"
-service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
+service:
+    annotations:
+        service.beta.kubernetes.io/aws-load-balancer-type: "external"
+        service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
 ```
 
 You can view a full list of possible annotations on [this page](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.2/guide/service/annotations).
@@ -25,8 +26,9 @@ You can view a full list of possible annotations on [this page](https://kubernet
 By default, OKE provisions a public IP for any `LoadBalancer` service. You can add the following annotation on the `service.annotations` field of the values file if you want OKE to provision an internal load balancer:
 
 ```yaml
-annotations:
-service.beta.kubernetes.io/oci-load-balancer-internal: "true"
+service:
+    annotations:
+        service.beta.kubernetes.io/oci-load-balancer-internal: "true"
 ```
 
 If needed, you can check [OCI](https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengcreatingloadbalancer.htm) docs for any special needs for your deployment.