Skip to content

Security & identity

There is no single security product on the platform. Access, isolation and secrecy are enforced by four separate Kubernetes mechanisms, each configured as an object in your project:

Mechanism Objects What it decides
Authorisation Role, RoleBinding which API operations an identity may perform, in which project
Network isolation NetworkPolicy which pods may open a connection to which
Secrecy Secret which credentials a pod receives at runtime rather than at build time
Workload identity ServiceAccount what a pod is itself authorised to do against the API

Because each is an object, each is readable with oc get, reviewable as a diff and enforced by the API server rather than by convention.

Isolation is chosen per workload: a namespace on shared infrastructure, a dedicated cluster, or dedicated hosts. Infrastructure is operated in the Netherlands, under Dutch and EU law.

What this section will cover

  • RBAC, roles and service accounts
  • Namespace isolation and micro-segmentation
  • Secrets handling and rotation
  • TLS and certificate management
  • Private endpoints
  • Compliance posture and the shared responsibility model

A baseline to apply now

  1. Bind the narrowest role that works — view before edit, edit before admin.
  2. Apply a default-deny egress NetworkPolicy, then allow what the workload needs.
  3. Keep credentials in Secrets injected at runtime, never in an image or in Git.
  4. Use short-lived service account tokens for automation.
oc get rolebindings -n <project> -o wide
oc get networkpolicy -n <project>

Identity for your own applications

The console's IAM perspective gives your project its own dedicated Keycloak identity server. This is the identity provider your applications authenticate their users against - it is separate from the login you use to reach the control panel itself.

Setting it up

Before a realm exists, the IAM perspective shows a setup page instead of the usual navigation.

Give it a domain name - a DNS-style name such as example.com, defaulting to your project name - and the platform provisions, in order: a dedicated PostgreSQL database, a dedicated Keycloak server, a connection to it, and a realm. This takes a few minutes; keep the page open and it reports progress per step.

If a step reports a failure, Retry is safe. Steps that already completed are not recreated - only the one that failed is retried.

Realms are not yet brokered into platform login

Setting up IAM does not add a "Sign in with <your project>" button to the GRN.CLOUD login page. That brokering step is not self-service yet - contact support if you need it.

What you end up with: a Keycloak server reachable in-cluster at keycloak-service.<your-project>.svc:8080, an initial admin credential in the keycloak-initial-admin Secret, and a realm ready for users, groups and clients.

Domains

A domain is a realm. One project can hold several, all served by the same Keycloak instance.

Once an instance exists, Create Domain adds another realm to it directly, rather than re-running the full provisioning wizard.

Because Kubernetes object names cannot contain dots, the object name is derived from the domain by replacing them with hyphens - example.com becomes example-com - while the realm keeps the domain exactly as you typed it.

Users

The people who log into your applications.

user.yaml
apiVersion: v1.edp.epam.com/v1
kind: KeycloakRealmUser
metadata:
  name: jdoe
  namespace: <your-project>
spec:
  realmRef:
    name: <your-domain>
  username: jdoe
  email: jdoe@example.com
  firstName: Jane
  lastName: Doe
  enabled: true
  keepResource: true
  groups:
  - admins

realmRef.name is the name of the KeycloakRealm object - the hyphenated form, if your domain contains dots.

Groups

Groups collect users so roles are assigned once rather than per person.

group.yaml
apiVersion: v1.edp.epam.com/v1
kind: KeycloakRealmGroup
metadata:
  name: admins
  namespace: <your-project>
spec:
  realmRef:
    name: <your-domain>
  name: admins

Clients

One OIDC client per application that authenticates against your realm.

client.yaml
apiVersion: v1.edp.epam.com/v1
kind: KeycloakClient
metadata:
  name: myapp
  namespace: <your-project>
spec:
  realmRef:
    name: <your-domain>
  clientId: myapp
  public: false
  standardFlowEnabled: true
  redirectUris:
  - "https://myapp.apps.grn.cloud/*"
  webOrigins:
  - "https://myapp.apps.grn.cloud"

Leave secret out for a confidential client and the operator generates one, storing it in a Secret named keycloak-client-<metadata.name>-secret. Set public: true for a client that cannot hold a secret, such as a single-page app.

Your application's OIDC discovery URL is https://<keycloak-host>/realms/<your-domain>/.well-known/openid-configuration.

How to

Step-by-step guides for each of these, in the console and as YAML: