Choose Existing Namespace for Zarf Init and Deploy

[ChevronTango]

Is your feature request related to a problem? Please describe.
We are currently trying to install zarf on an OpenShift cluster. One of the limitations for this is that you only get given a single "Project" in OpenShift, which is the namespace you are allowed to deploy into. You cannot deploy or create additional namespaces for your project. When deploying zarf init, it wants to create a zarf namespace to deploy the init resources, but this is not an option in OpenShift.

Describe the solution you'd like
A way to specify on zarf init and deploy, a single namespace that everything should sit in. The logical separation of resources is a luxury when you only have one NS you can use for everything.

Describe alternatives you've considered
Having multiple projects, one called zarf and the other for each deployment might work, but only if everyone agreed to use the shared zarf project to master everything, and permissions were granted to allow this. Different teams and projects should then be able to deploy just their application (assuming no additional namespaces are needed to be created).

Additional context
Zarf should work in OpenShift in an environment where you have one and only one immutable namespace.
multiple projects don't have to live in the same namespace, but crucially the zarf namespace used in init either needs to be customizable or optional.

[jeff-mccoy]

Thanks for opening the issue; we do need to add more testing around Openshift. Not sure if this is helpful, but a team gave us this a few months ago for OCP 4.6:

# zarf-security.yml
apiVersion: v1
kind: Namespace
metadata:
  name: zarf
---
apiVersion: [rbac.authorization.k8s.io/v1](https://github.com/defenseunicorns/zarf/issues/rbac.authorization.k8s.io/v1)
kind: Role
metadata:
  name: privileged-scc
  namespace: zarf
rules:
- apiGroups:
  - [security.openshift.io](https://github.com/defenseunicorns/zarf/issues/security.openshift.io)
  resourceNames:
  - privileged
  resources:
  - securitycontextconstraints
  verbs:
  - use
---
apiVersion: [rbac.authorization.k8s.io/v1](https://github.com/defenseunicorns/zarf/issues/rbac.authorization.k8s.io/v1)
kind: RoleBinding
metadata:
  name: zarf-privileged-scc-bind
  namespace: zarf
subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: [rbac.authorization.k8s.io](https://github.com/defenseunicorns/zarf/issues/rbac.authorization.k8s.io)
  namespace: zarf
roleRef:
  kind: Role
  name: privileged-scc
  apiGroup: [rbac.authorization.k8s.io](https://github.com/defenseunicorns/zarf/issues/rbac.authorization.k8s.io)

We have a large refactor, #934, that will make looking at something like changing the zarf namespace slightly less difficult, but it's still going to be something we really have to think through to make this work.

[laurentiusoica]

I also have this use case for target multi-tenant clusters that I don't own and where I'm just a regular user with access to a single namespace. Maybe one way is to get the namespace as argument for init, and add a label on the zarf state secret so that at deploy time zarf can scan the cluster and identify the state secret based on the label?

[gjacobitrs]

Our team is facing the exact same use case whereby we usually get access to a single namespace.