Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update deployment steps to use the new Helm chart #9

Merged
merged 16 commits into from
Aug 19, 2024
Merged
Show file tree
Hide file tree
Changes from 12 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 25 additions & 33 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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>
```

Expand All @@ -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.
Expand Down Expand Up @@ -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
```

Expand Down Expand Up @@ -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>
```

Expand Down
13 changes: 7 additions & 6 deletions docs/certificates.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
36 changes: 17 additions & 19 deletions docs/database-accounts/environment-variables.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
...
```
31 changes: 9 additions & 22 deletions docs/metrics.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,36 +7,23 @@ 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

### Service Monitor discovery configuration

The sidecar `helm` chart packages a `ServiceMonitor` object which can be used
in conjunction with a [`prometheus operator`](https://github.com/prometheus-operator/prometheus-operator) to
monitor all pods in the sidecar's `Deployment`. To enable the service monitor, you
can add the following to your `values.yaml` file:

```yaml
metrics:
serviceMonitor:
enabled: true
```

**NOTE:** There are many other configuration options for the `ServiceMonitor` object,
you can look at the default `values.yaml` file to know all the options.

### Annotation based Prometheus discovery configuration

You can add common `Prometheus` annotations by adding the following
Expand Down
80 changes: 43 additions & 37 deletions docs/port-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
7 changes: 3 additions & 4 deletions docs/pre-existing-sa.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
```
12 changes: 7 additions & 5 deletions docs/public-load-balancer.md
Original file line number Diff line number Diff line change
Expand Up @@ -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).
Expand All @@ -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.
Expand Down
Loading