Skip to content

Commit 8e4696e

Browse files
mcrowsonmcrowson
committed
shra 1.4.0 release
1 parent cfa5f51 commit 8e4696e

File tree

3 files changed

+67
-8
lines changed

3 files changed

+67
-8
lines changed

‎helm-charts/falcon-self-hosted-registry-assessment/Chart.yaml

+2-2
Original file line numberDiff line numberDiff line change
@@ -15,10 +15,10 @@ type: application
1515
# This is the chart version. This version number should be incremented each time you make changes
1616
# to the chart and its templates, including the app version.
1717
# Versions are expected to follow Semantic Versioning (https://semver.org/)
18-
version: 1.3.0
18+
version: 1.4.0
1919

2020
# This is the version number of the application being deployed. This version number should be
2121
# incremented each time you make changes to the application. Versions are not expected to
2222
# follow Semantic Versioning. They should reflect the version the application is using.
2323
# It is recommended to use it with quotes.
24-
appVersion: "1.3.0"
24+
appVersion: "1.4.0"

‎helm-charts/falcon-self-hosted-registry-assessment/README.md

+63-4
Original file line numberDiff line numberDiff line change
@@ -224,12 +224,16 @@ Create your client ID and secret:
224224
> [!NOTE]
225225
> The API client secret will not be presented again, so don't close the dialog until you have this value safely saved.
226226

227-
Export these variables for use in later steps:
227+
Export these variables for use in later steps when configuring the logscale exporter:
228228
```sh
229229
export FALCON_CLIENT_ID=<your-falcon-api-client-id>
230230
export FALCON_CLIENT_SECRET=<your-falcon-api-client-secret>
231231
```
232232

233+
There are two options for setting your CrowdStrike client id and secret for SHRA: explicitly in helm or via kubernetes secrets/configmaps.
234+
235+
#### Option 1. Explicitly Set CrowdStrike credentials in values_override.yaml
236+
233237
In your `values_override.yaml` file, set `crowdstrikeConfig.clientID` and `crowdstrikeConfig.clientSecret` to the values you saved in `FALCON_CLIENT_ID` and `FALCON_CLIENT_SECRET`.
234238

235239
For example,
@@ -244,6 +248,53 @@ crowdstrikeConfig:
244248
| `crowdstrikeConfig.clientID` | required | The client id used to authenticate the self-hosted registry assessment service with CrowdStrike. | "" |
245249
| `crowdstrikeConfig.clientSecret` | required | The client secret used to authenticate the self-hosted registry assessment service with CrowdStrike. | "" |
246250

251+
252+
#### Option 2. Set CrowdStrike credentials using existing Kubernetes secret or configmap
253+
254+
You can use existing Kubernetes secrets or configmaps to provide your CrowdStrike credential environment variables to the SHRA pods. This is useful when you want to manage credential settings separately from the Helm chart deployment.
255+
256+
You may already have a secret or configmap you want to use, otherwise create your Kubernetes secret or configmap in the falcon-self-hosted-registry-assessment namespace.
257+
It must contain both of the following keys:
258+
- CLIENT_ID
259+
- CLIENT_SECRET
260+
For example, create a Kubernetes a secret:
261+
262+
```sh
263+
kubectl create secret generic crowdstrike-credentials \
264+
--namespace falcon-self-hosted-registry-assessment \
265+
--from-literal=CLIENT_ID="aabbccddee112233445566aabbccddee" \
266+
--from-literal=CLIENT_SECRET="aabbccddee112233445566aabbccddee11223344"
267+
```
268+
269+
If using a Kubernetes secret, add the following reference to your values_override.yaml file in executor section. Update name to match the name of your secret.
270+
271+
```yaml
272+
executor:
273+
additionalSecretEnvFrom:
274+
- name: "crowdstrike-credentials"
275+
optional: false
276+
```
277+
278+
If using a Kubernetes configmap, add the following references to your values_override.yaml file in the executor section. Update name to match the name of your configmap.
279+
```yaml
280+
executor:
281+
additionalCMEnvFrom:
282+
- name: "crowdstrike-credentials"
283+
optional: false
284+
```
285+
286+
The `name` field references the secret name that is already created (here matching the secret we created in step 0):
287+
288+
The `optional` field determines whether the pods will start if the secret is missing:
289+
- `optional: false` (default) - Pods will fail to start if the secret doesn't exist
290+
- `optional: true` - Pods will start even if the secret is missing
291+
292+
After completing the remaining steps to configure and install SHRA, return here to verify that the environment variables are properly configured in the pod's environment:
293+
294+
```sh
295+
kubectl exec -n falcon-self-hosted-registry-assessment <pod-name> -- env | grep -i client
296+
```
297+
247298
### Copy the SHRA images to your registry
248299

249300
To strengthen your container supply chain security and maintain security best practices, we recommend you deploy the SHRA containers from your private registry.
@@ -538,7 +589,7 @@ Continue to add additional registries, or proceed to [Validate your registry cre
538589

539590
Copy this registry configuration to your `values_override.yaml` file and provide the required information.
540591

541-
* `domain_url` and `host` should both be the fully qualified domain name of your Githab installation. The values provided in the example below are for Github cloud.
592+
* `domain_url` and `host` should both be the fully qualified domain name of your Github installation. The values provided in the example below are for Github cloud.
542593

543594
```yaml
544595
- type: github
@@ -1027,6 +1078,10 @@ Add and adjust the following lines in your `values_override.yaml` file to config
10271078
| `jobController.dbStorage.accessModes` | | Array of access modes for the job controller's database claim. | "- ReadWriteOnce" |
10281079
| `jobController.dbStorage.storageClass` |required | Storage class to use when creating a persistent volume claim for the job controller database. Examples include "ebs-sc" in AKS and "standard" in GKE. | "" |
10291080

1081+
#### Storage Driver Considerations When Sharing a Persistent Volume Claim for Executor Database Storage
1082+
1083+
The primary focus of the Executor Database is to act as a local cache so that SHRA is aware of what it has already scanned and to speed up future assessments. If you are running multiple executor pods, they could share a single database and the database will be shared across all pods making them aware of the work of each other. The `executor.dbStorage.accessModes` field is set to `ReadWriteOnce` by default as this mode is supported by all storage drivers, however it prohibits sharing of a single database volume across pods. If you will be using multiple executor pods and wish to share a executor database, you will need to use the `ReadWriteMany` setting. Be sure that your storageClass supports this mode.
1084+
10301085
#### Change persistent storage retention
10311086

10321087
To reduce the footprint of the `job controller` database, you can adjust data retention periods for each of the three main jobs it schedules for `executor`.
@@ -1082,7 +1137,11 @@ Configure your temporary storage location by editing the following lines to your
10821137
| `executor.assessmentStorage.pvc.create` | | If `true`, creates the persistent volume claim for assessment storage. Default setting is to create a PVC unless you modify the config. | true |
10831138
| `executor.assessmentStorage.pvc.existingClaimName` | | An existing storage claim name you wish to use instead of the one created above. Required if `executor.assessmentStorage.pvc.create` is false. | "" |
10841139
| `executor.assessmentStorage.pvc.storageClass` |required | Storage class to use when creating a persistent volume claim for the assessment storage. Examples include "ebs-sc" in AKS and "standard" in GKE. | "" |
1085-
| `executor.assessmentStorage.pvc.accessModes` | | Array of access modes for this database claim. | "- ReadWriteOnce" |
1140+
| `executor.assessmentStorage.pvc.accessModes` | | Array of access modes for the assessment storage volume claim. | "- ReadWriteOnce" |
1141+
1142+
#### Storage Driver Considerations When Sharing a Persistent Volume Claim for Assessment Storage
1143+
1144+
The `executor.assessmentStorage.pvc.accessModes` field is set to `ReadWriteOnce` by default as this mode is supported by all storage drivers. If you will be using multiple executor pods to that will share a single volume for unpacking images, you will need to use the `ReadWriteMany` setting. Be sure that your storageClass supports this mode.
10861145

10871146
### Configure SHRA scaling to meet your scanning needs
10881147

@@ -1520,7 +1579,7 @@ The Chart's `values.yaml` file includes more comments and descriptions in-line f
15201579
| `executor.assessmentStorage.pvc.create` | | If `true`, creates the persistent volume claim for assessment storage. Default setting is to create a PVC unless you modify the config. | true |
15211580
| `executor.assessmentStorage.pvc.existingClaimName` | | An existing storage claim name you wish to use instead of the one created above. Required if `executor.assessmentStorage.pvc.create` is `false`. | "" |
15221581
| `executor.assessmentStorage.pvc.storageClass` | required | Storage class to use when creating a persistent volume claim for the assessment storage. Examples include "ebs-sc" in AKS and "standard" in GKE. | "" |
1523-
| `executor.assessmentStorage.pvc.accessModes` | | Array of access modes for the assessment storage volume claim. | "- ReadWriteOnce" |
1582+
| `executor.assessmentStorage.pvc.accessModes` | | Array of access modes for the assessment storage volume claim. Please see [Storage Driver Considerations](#storage-driver-considerations-when-sharing-a-persistent-volume-claim-for-assessment-storage) if you should set this to ReadWriteMany | "- ReadWriteOnce" |
15241583
| `executor.logLevel` | | Log level for the `executor` service (1:error, 2:warning, 3:info, 4:debug) | 3 |
15251584
| `executor.labels` | | Additional labels to apply to the executor pods. | {} |
15261585
| `executor.podAnnotations` | | Additional pod annotations to apply to the executor pods. | {} |

‎helm-charts/falcon-self-hosted-registry-assessment/values.yaml

+2-2
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ executor:
1212
# Overrides the image tag. In general, tags should not be used (including semver tags or `latest`).
1313
# This variable is provided for those who have yet to move off of using tags. The sha256 digest
1414
# should be used in place of tags for increased security and image immutability.
15-
tag: "1.3.0"
15+
tag: "1.4.0"
1616
# Setting a digest will override any tag and should be used instead of tags.
1717
#
1818
# Example digest variable configuration:
@@ -100,7 +100,7 @@ jobController:
100100
repository: "jobcontroller"
101101
# Overrides the image tag. In general, tags should not be used (including semver tags or `latest`). This variable is provided for those
102102
# who have yet to move off of using tags. The sha256 digest should be used in place of tags for increased security and image immutability.
103-
tag: "1.3.0"
103+
tag: "1.4.0"
104104
# Setting a digest will override any tag and should be used instead of tags.
105105
#
106106
# Example digest variable configuration:

0 commit comments

Comments
 (0)