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: README.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ You can add these Kubernetes annotations to specific DevWorkspace CR to customiz
16
16
17
17
The `controller.devfile.io/restricted-access` specifies that a DevWorkspace needs additional access control (in addition to RBAC). When a DevWorkspace is created with the `controller.devfile.io/restricted-access` annotation set to `true`, the webhook server will guarantee
18
18
- Only the DevWorkspace Operator ServiceAccount or DevWorkspace creator can modify important fields in the devworksapce
19
-
- Only the DevWorkspace creator can create `pods/exec` into workspace-related containers.
19
+
- Only the DevWorkspace creator can create `pods/exec` into devworkspace-related containers.
20
20
21
21
This annotation should be used when a DevWorkspace is expected to contain sensitive information that should be protect above the protection provided by standard RBAC rules (e.g. if the DevWorkspace will store the user's OpenShift token in-memory).
By default, controller will expose workspace servers without any authentication; this is not advisable for public clusters, as any user could access the created workspace via URL.
52
+
By default, controller will expose devworkspace servers without any authentication; this is not advisable for public clusters, as any user could access the created devworkspace via URL.
53
53
54
54
In case of OpenShift, you're able to configure DevWorkspace CR to secure your servers with the following piece of configuration:
55
55
@@ -95,9 +95,9 @@ Some of the rules supported by the makefile:
95
95
To see all rules supported by the makefile, run `make help`
96
96
97
97
### Test run controller
98
-
1. Take a look samples workspace configuration in `./samples` folder.
99
-
2. Apply any of them by executing `kubectl apply -f ./samples/workspace_java_mysql.yaml -n <namespace>`
100
-
3. As soon as workspace is started you're able to get IDE url by executing `kubectl get devworkspace -n <namespace>`
98
+
1. Take a look samples devworkspace configuration in `./samples` folder.
99
+
2. Apply any of them by executing `kubectl apply -f ./samples/flattened_theia-next.yaml -n <namespace>`
100
+
3. As soon as devworkspace is started you're able to get IDE url by executing `kubectl get devworkspace -n <namespace>`
When running locally, only a single namespace is watched; as a result, all workspaces have to be deployed to `${NAMESPACE}`
109
+
When running locally, only a single namespace is watched; as a result, all devworkspaces have to be deployed to `${NAMESPACE}`
110
110
111
111
### Run controller locally and debug
112
112
Debugging the controller depends on `delve` being installed (`go get -u github.com/go-delve/delve/cmd/dlv`). Note that at the time of writing, executing `go get` in this repo's directory will update go.mod; these changes should be dropped before committing.
0 commit comments