User Access to CodeNOW Cluster

CodeNOW allows users to access the underlying Kubernetes cluster directly via kubeconfig. This enables the use of standard Kubernetes tooling (kubectl, k9s, IDE plugins, mirrord for remote debugging, etc.) against the cluster that hosts your environments.

Prerequisites

To connect to the cluster you need the following tools installed locally:

• kubectl — the standard Kubernetes CLI used to interact with the cluster
• pinniped — the authentication client used by CodeNOW for user authentication and authorization against the cluster. The downloaded kubeconfig uses the pinniped CLI directly to perform the OIDC login flow on each connection

Downloading the Kubeconfig

The kubeconfig file is available on the Cluster Detail page under the Cluster Access link. Downloading it requires the cluster to have user access configured and the user to have at least the Viewer, Developer, or Admin role on that cluster — see Cluster Permissions.

The kubeconfig uses the pinniped CLI to perform the OIDC login flow via CodeNOW's identity provider at connection time. An example kubeconfig looks like this:

apiVersion: v1
clusters:
  - cluster:
      server: https://kubeapi.<cluster-domain>
    name: cn-<account-name>-<cluster-name>
contexts:
  - context:
      cluster: cn-<account-name>-<cluster-name>
      user: user
    name: cn-<account-name>-<cluster-name>
current-context: cn-<account-name>-<cluster-name>
kind: Config
preferences: {}
users:
  - name: user
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1beta1
        args:
          - login
          - oidc
          - --enable-concierge
          - --concierge-authenticator-name=cn-user-authenticator
          - --concierge-authenticator-type=jwt
          - --concierge-endpoint=https://kubeapi.<cluster-domain>
          - --issuer=https://iam.cloud.codenow.com/auth/realms/codenow
          - --client-id=<account-name>-<cluster-name>-pinniped
          - --scopes=openid,email
        command: pinniped
        env: []
        installHint: The pinniped CLI does not appear to be installed.  See https://get.pinniped.dev/cli
          for more details
        provideClusterInfo: true

note

Namespace-level permissions are not configured on the cluster. They are propagated automatically from the Environment Permissions settings.

Access Model

Access is two-layered:

Cluster level

Controls whether a user can connect to the cluster at all (download kubeconfig, list namespaces). Managed via Cluster Permissions.

Role	Cluster access
Admin	Download kubeconfig, list namespaces
Developer	Download kubeconfig, list namespaces
Viewer	Download kubeconfig, list namespaces

Environment (namespace) level

Controls what the user can do inside each environment's Kubernetes namespace. Managed via Environment Permissions and propagated automatically — no manual RBAC configuration in the cluster is needed.

Role	Kubernetes namespace permissions
Admin	Full access including delete on all objects
Deployer	get, list, watch, create, update, patch on all objects; delete on pods
Viewer	get, list, watch on all objects

A user must have access on both levels: cluster access to connect, and environment access to interact with resources in a given namespace.

Common Use Cases

• Inspecting running workloads — use kubectl or a Kubernetes IDE plugin with the downloaded kubeconfig to browse pods, logs, and events in your environment's namespace
• Remote debugging — mirrord requires the kubeconfig of the cluster hosting the target environment; see Remote Debug
• Troubleshooting deployments — direct namespace access lets you inspect resource states, describe pods, or stream logs without going through the CodeNOW UI