# Guidance when installing on Open Shift? **URL:** \ **Category:** Supporting your customers\ **Tags:** kots, support, openshift\ **Created:** [March 29, 2023, 7:43am UTC](https://community.replicated.com/t/guidance-when-installing-on-open-shift/1167 "2023-03-29T07:43:33Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Alexander\_Nitu](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.replicated.com/alexander_nitu/32/535_2.png) [@Alexander\_Nitu](https://community.replicated.com/u/Alexander_Nitu)\ **Post date:** [March 29, 2023, 7:43am UTC](https://community.replicated.com/t/guidance-when-installing-on-open-shift/1167/1 "2023-03-29T07:43:33Z")
Hello! We are going to do an installation in an OpenShift environment. We usually just go with embedded installations so we don’t know much about this. Are there any guidance you can share when doing such a type of installation? Any general questions it would be helpful to ask the customer before so that we are better prepared? Any specific things we can do or need to pay attention to? Any help would be appreciated. Thanks! ---
**Author:** ![dex](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.replicated.com/dex/32/26_2.png) [@dex](https://community.replicated.com/u/dex)\ **Post date:** [March 29, 2023, 2:59pm UTC](https://community.replicated.com/t/guidance-when-installing-on-open-shift/1167/2 "2023-03-29T14:59:14Z")
I can say that a lot of problems that may seem “unique to openshift” often are less “openshift specific” problems, and more like “locked-down security postures that could happen in any cluster, but are much more likely to show up in openshift clusters”. These include: - Requiring use of an existing service account instead one created by the KOTS CLI - Requiring airgap - Requiring a specific namespace, and that all workloads and service accounts be scoped to that one single namespace There are, of course, some openshift-specific things that are almost certain to come up - Requiring containers to run as non-root - Blocking `privileged` and other flags that open the door to container privilege escalation **In all cases** , please ensure you provision and test in an Openshift cluster internally, or you’re certainly in for some surprises on launch day. Start drafting your documentation before you go to install with the customer. Have someone on your team playtest the documentation to make sure _they_ can follow and succeed with it. As for resources, this won’t be comprehensive, but I’d check out > [@Existing Cluster Install: Using Custom RBAC roles](https://community.replicated.com/t/existing-cluster-install-using-custom-rbac-roles/876): > > Question from this week about using custom / BYO RBAC roles when installing App Manager (KOTS) into an existing kubernetes cluster – specifically Openshift in this case. Our Openshift cluster has a built-in role admin that we’d like to use instead of the role created by kubectl kots install --use-minimal-rbac or oc kots install --use-minimal-rbac. Because the admin account permissions are slightly more narrow than the kots-created RBAC role, the installation fails if a user with the admin role… > **[Online Installation in Existing Clusters | Replicated Docs](https://docs.replicated.com/enterprise/installing-existing-cluster#air-gap)** > > Prerequisites > [@Managing Custom Namespaces in a secured environment](https://community.replicated.com/t/managing-custom-namespaces-in-a-secured-environment/922): > > Great Question from today: We are trying to template below toggles under the kots-app config with no success, requireMinimalRBACPrivileges additionalNamespaces We need to be able to let our customer to control these toggle on deployment, and specify the namespace accordingly for minimal RBAC permissions Put another way, at least as I understand it, this comes down to “My customer only wants to give me access to one or more specific namespaces, and I want to make this customizable for them” … There are many vendor documentation examples in [Help creating Replicated Documentation For end user Kubernetes installs?](https://community.replicated.com/t/help-creating-replicated-documentation-for-end-user-kubernetes-installs/811), and a few openshift-specific deep-links provided below from industry leaders: - [https://docs.swimlane.com/install/Swimlane\_Platform\_Installer/Existing\_Cluster\_Install/Install\_Into\_an\_Online\_OpenShift\_Cluster](https://docs.swimlane.com/install/Swimlane_Platform_Installer/Existing_Cluster_Install/Install_Into_an_Online_OpenShift_Cluster) - [https://support.smartbear.com/swaggerhub/docs/enterprise/latest/install/cluster/online-openshift.html](https://support.smartbear.com/swaggerhub/docs/enterprise/latest/install/cluster/online-openshift.html) ---
**Author:** ![bco](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.replicated.com/bco/32/482_2.png) [@bco](https://community.replicated.com/u/bco)\ **Post date:** [April 3, 2023, 11:07am UTC](https://community.replicated.com/t/guidance-when-installing-on-open-shift/1167/3 "2023-04-03T11:07:01Z")
One major gotcha with OpenShift is that containers run as an arbitrary uid. The uid is injected into /etc/passwd at container startup and the user is a member of the root group. The behavior can be disabled but our customers generally have policies preventing this. The effect of this is that any files or folders that need to be writable within the container must be writable by the root group. See “Support Arbitrary User IDs” in the OpenShift docs: [Guidelines | Creating Images | OpenShift Container Platform 3.11](https://docs.openshift.com/container-platform/3.11/creating_images/guidelines.html)