Skip to content
This repository has been archived by the owner on Aug 19, 2024. It is now read-only.

Documentation for security mitigation #182

Merged
merged 3 commits into from
Feb 8, 2024
Merged

Documentation for security mitigation #182

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ac65bf6
Documemtation for security mitigation
jianrongzhang89 Jan 31, 2024
82fc438
rename openshift-rhdh-operator to rhdh-operator for suggested namespace
jianrongzhang89 Feb 2, 2024
369f4a1
Update docs/admin.md
rm3l Feb 7, 2024
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
2 changes: 1 addition & 1 deletion .rhdh/bundle/manifests/rhdh-operator.csv.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,7 +25,7 @@ metadata:
It comes with pre-built plug-ins, configuration settings, and deployment mechanisms,
which can help streamline the process of setting up a self-managed internal
developer portal for adopters who are just starting out.
operatorframework.io/suggested-namespace: openshift-rhdh-operator
operatorframework.io/suggested-namespace: rhdh-operator
operators.openshift.io/valid-subscription: '["OpenShift Container Platform", "OpenShift
Platform Plus"]'
operators.operatorframework.io/builder: operator-sdk-v1.33.0
Expand Down
8 changes: 7 additions & 1 deletion docs/admin.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,8 @@ kubectl get -n backstage-system configmap default-config > my-config.yaml

It has to be re-applied to the controller's container after being reconciled by kubernetes processes.

### Recommended Namespace for Operator Installation
It is recommended to deploy the Backstage Operator in a dedicated default namespace `backstage-system`. The cluster administrator can restrict access to the operator resources through RoleBindings or ClusterRoleBindings. On OpenShift, you can choose to deploy the operator in the `openshift-operators` namespace instead. However, you should keep in mind that the Backstage Operator shares the namespace with other operators and therefore any users who can create workloads in that namespace can get their privileges escalated from all operators' service accounts.

### Use Cases

Expand All @@ -96,4 +98,8 @@ By default, the Backstage Operator is configured to use publicly available image
If you plan to deploy to a [restricted environment](https://docs.openshift.com/container-platform/4.14/operators/admin/olm-restricted-networks.html),
you will need to configure your cluster or network to allow these images to be pulled.
For the list of related images deployed by the Operator, see the `RELATED_IMAGE_*` env vars or `relatedImages` section of the [CSV](../bundle/manifests/backstage-operator.clusterserviceversion.yaml).
See also https://docs.openshift.com/container-platform/4.14/operators/admin/olm-restricted-networks.html
See also https://docs.openshift.com/container-platform/4.14/operators/admin/olm-restricted-networks.html

#### Custom Backstage Image

You can use the Backstage Operator to deploy a backstage application with your custom backstage image by setting the field `spec.application.image` in your Backstage CR. This is at your own risk and it is your responsibility to ensure that the image is from trusted sources, and has been tested and validated for security compliance.