You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/operator-manual/upgrading/2.14-3.0.md
+26-22
Original file line number
Diff line number
Diff line change
@@ -35,25 +35,27 @@ Starting from 3.0, this flag is removed and the logs RBAC is enforced by default
35
35
36
36
#### Detection
37
37
38
-
Users who have `server.rbac.log.enforce.enable: "true"` in their `argocd-cm` ConfigMap, are unaffected by this change.
38
+
Users who have `server.rbac.log.enforce.enable: "true"` in their `argocd-cm` ConfigMap, are unaffected by this change.
39
39
40
-
Users who have `policy.default: role:readonly` or `policy.default: role:admin` in their `argocd-rbac-cm` ConfigMap, are unaffected.
40
+
Users who have `policy.default: role:readonly` or `policy.default: role:admin` in their `argocd-rbac-cm` ConfigMap, are unaffected.
41
41
42
-
Users who don't have a `policy.default` in their `argocd-rbac-cm` ConfigMap, and either have `server.rbac.log.enforce.enable` set to `false` or don't have this setting at all in their `argocd-cm` ConfigMap are affected and should perform the below remediation steps.
42
+
Users who don't have a `policy.default` in their `argocd-rbac-cm` ConfigMap, and either have `server.rbac.log.enforce.enable` set to `false` or don't have this setting at all in their `argocd-cm` ConfigMap are affected and should perform the below remediation steps.
43
43
44
-
After the upgrade, it is recommended to remove the setting `server.rbac.log.enforce.enable` from `argocd-cm` ConfigMap, if it was there before the upgrade.
44
+
After the upgrade, it is recommended to remove the setting `server.rbac.log.enforce.enable` from `argocd-cm` ConfigMap, if it was there before the upgrade.
45
45
46
46
#### Remediation
47
47
48
-
##### Quick remediation (global change)
49
-
For users with an existing default policy with a custom role, add this policy to `policy.csv` for your custom role: `p, role:<YOUR_DEFAULT_ROLE>, logs, get, */*, allow`.
50
-
For users without a default policy, add this policy to `policy.csv`: `p, role:global-log-viewer, logs, get, */*, allow`and add the default policy for this role: `policy.default: role:global-log-viewer`
48
+
##### Quick remediation (global change)
49
+
50
+
For users with an existing default policy with a custom role, add this policy to `policy.csv` for your custom role: `p, role:<YOUR_DEFAULT_ROLE>, logs, get, */*, allow`.
51
+
For users without a default policy, add this policy to `policy.csv`: `p, role:global-log-viewer, logs, get, */*, allow`and add the default policy for this role: `policy.default: role:global-log-viewer`
51
52
52
53
##### Recommended remediation (per-policy change)
53
-
Explicitly add a `logs, get` policy to every role that has a policy for `applications, get` or for `applications, *`.
54
-
This is the recommended way to maintain the principle of least privilege.
55
-
Similar to the way access to Applications are currently managed, access to logs can be either granted on a Project scope level (Project resource) or on the `argocd-rbac-cm` ConfigMap level.
56
-
See this [example](../upgrading/2.3-2.4.md#example-1) for more details.
54
+
55
+
Explicitly add a `logs, get` policy to every role that has a policy for `applications, get` or for `applications, *`.
56
+
This is the recommended way to maintain the principle of least privilege.
57
+
Similar to the way access to Applications are currently managed, access to logs can be either granted on a Project scope level (Project resource) or on the `argocd-rbac-cm` ConfigMap level.
58
+
See this [example](../upgrading/2.3-2.4.md#example-1) for more details.
57
59
58
60
### Default `resource.exclusions` configurations
59
61
@@ -63,7 +65,7 @@ which we exclude for performance reasons, reducing connections and load to the K
- **Kyverno**: `EphemeralReport`, `ClusterEphemeralReport`, `AdmissionReport`, `ClusterAdmissionReport`, `BackgroundScanReport`, `ClusterBackgroundScanReport` and `UpdateRequest`.
69
71
- **Cilium**: `CiliumIdentity`, `CiliumEndpoint` and `CiliumEndpointSlice`.
@@ -216,26 +218,28 @@ spec:
216
218
namespace: guestbook
217
219
```
218
220
219
-
### Upgraded Helm version with breaking changes
220
-
Helm was upgraded to 3.17.1.
221
-
This may require changing your `values.yaml` files for subcharts, if the `values.yaml` contain a section with a `null` object.
222
-
See related issue in [Helm GitHub repository](https://github.com/helm/helm/issues/12469)
223
-
See Helm 3.17.1 [release notes](https://github.com/helm/helm/releases/tag/v3.17.1)
224
-
Example of such a [problem and resolution](https://github.com/argoproj/argo-cd/pull/22035/files)
221
+
### Upgraded Helm version with breaking changes
222
+
223
+
Helm was upgraded to 3.17.1.
224
+
This may require changing your `values.yaml` files for subcharts, if the `values.yaml` contain a section with a `null` object.
225
+
See related issue in [Helm GitHub repository](https://github.com/helm/helm/issues/12469)
226
+
See Helm 3.17.1 [release notes](https://github.com/helm/helm/releases/tag/v3.17.1)
227
+
Example of such a [problem and resolution](https://github.com/argoproj/argo-cd/pull/22035/files)
225
228
Explanation:
229
+
226
230
- Prior to Helm 3.17.1, `null` object in `values.yaml` resulted in a warning: `cannot overwrite table with non table`upon performing `helm template`, and the resulting K8s object was not overridden with the invalid `null` value.
227
231
- In Helm 3.17.1, this behavior changed and `null` object in `values.yaml` still results in this warning upon performing `helm template`, but the resulting K8s object will be overridden with the invalid `null` value.
228
-
- To resolve the issue, identify `values.yaml` with `null` object values, and remove those `null` values.
232
+
- To resolve the issue, identify `values.yaml` with `null` object values, and remove those `null` values.
229
233
230
234
### Use Annotation-Based Tracking by Default
231
235
232
-
The default behavior for [tracking resources](../../user-guide/resource_tracking.md) has changed to use annotation-based
233
-
tracking instead of label-based tracking. Annotation-based tracking is more reliable and less prone to errors caused by
236
+
The default behavior for [tracking resources](../../user-guide/resource_tracking.md) has changed to use annotation-based
237
+
tracking instead of label-based tracking. Annotation-based tracking is more reliable and less prone to errors caused by
234
238
external code copying tracking labels from one resource to another.
235
239
236
240
#### Detection
237
241
238
-
To detect if you are impacted, check the `argocd-cm` ConfigMap for the `application.resourceTrackingMethod` field. If it
242
+
To detect if you are impacted, check the `argocd-cm` ConfigMap for the `application.resourceTrackingMethod` field. If it
239
243
unset or is set to `label`, you are using label-based tracking. If it is set to `annotation`, you are already using
240
244
annotation-based tracking and are not impacted by this change.
0 commit comments