Here is an example using GKE: https://github.com/pulumi/examples/blob/master/gcp-ts-gke/cluster.ts To create a cluster role, you can do something like this:

const clusterRole = new k8s.rbac.v1.ClusterRole(
  'cluster-role-name',
  {
    // options here...
  },
  {
    provider: k8sProvider,
  },
);

@faint-motherboard-95438?

So that might look something like this:

// The ServiceAccount that will manage Kubernetes resources as part of CI.
export const gcpServiceAccount = new gcp.serviceAccount.Account(`${config.appName}`, {
    accountId: config.appName,
    displayName: "Test CI"
});

// The key that we will place in the Travis CI using `travis encrypt`.
export const gcpServiceAccountKey = new gcp.serviceAccount.Key(config.appName, {
    serviceAccountId: gcpServiceAccount.name
});

export const testCiRole = new gcp.projects.IAMCustomRole(config.appName, {
    roleId: "testci",
    title: "Test CI role",
    project: config.project,
    permissions: [...]
});

// Grants the ServiceAccount the ability to use the gcloud container API.
export const gcpCiRole = new gcp.projects.IAMBinding(config.appName, {
    // role: "projects/pulumi-development/roles/KubernetesTestCIRole",
    role: testCiRole.id,
    members: [gcpServiceAccount.email.apply(email => `serviceAccount:${email}`)]
});

// Grants the ServiceAccount the ability to use the gcloud container API.
const saUser = new gcp.projects.IAMBinding(`${config.appName}-sa`, {
    role: "roles/iam.serviceAccountUser",
    members: [gcpServiceAccount.email.apply(email => `serviceAccount:${email}`)]
});

// Grant the ServiceAccount admin permissions inside the Kubernetes cluster.
export const k8sRoleBinding = new k8s.rbac.v1.ClusterRoleBinding(
    "cluster-admin-binding",
    {
        metadata: { name: "cluster-admin-binding" },
        roleRef: {
            apiGroup: "<http://rbac.authorization.k8s.io|rbac.authorization.k8s.io>",
            kind: "ClusterRole",
            name: "cluster-admin"
        },
        subjects: [
            { apiGroup: "<http://rbac.authorization.k8s.io|rbac.authorization.k8s.io>", kind: "User", name: gcpServiceAccount.email }
        ]
    },
    { provider: k8sProvider }
);

export const clientSecret = gcpServiceAccountKey.privateKey.apply(key =>
    JSON.parse(Buffer.from(key, "base64").toString("ascii"))
);

@creamy-potato-29402 actually I have one last problem that was hidden I just discovered after having cleaned up everything to be sure I was ok. I need to provide a

kubeconfig

to the

k8sProvider

, and I’m kind of lost on what I should put in it to authenticate the serviceAccount I use and to whom I have granted the permissions I needed. By default it uses the

kubectl

active config and if I put

auth-provider:
  config:
     cmd-args: config config-helper --format=json
     cmd-path: gcloud
     expiry-key: '{.credential.token_expiry}'
     token-key: '{.credential.access_token}'
   name: gcp

it uses the

gcloud

config which is not what I want either. I can’t find what I should put here and from where.. could you help me on this one too ?

If you take something like this:

import * as k8s from "@pulumi/kubernetes";
import * as gcp from "@pulumi/gcp";

import { k8sProvider } from "./cluster";
import * as config from "./config";

// The ServiceAccount that will manage Kubernetes resources as part of CI.
export const gcpServiceAccount = new gcp.serviceAccount.Account(`${config.appName}`, {
    accountId: config.appName,
    displayName: "Test CI"
});

// The key that we will place in the Travis CI using `travis encrypt`.
export const gcpServiceAccountKey = new gcp.serviceAccount.Key(config.appName, {
    serviceAccountId: gcpServiceAccount.name
});

// Grants the ServiceAccount the ability to use the gcloud container API.
export const gcpCiRole = new gcp.projects.IAMBinding(config.appName, {
    role: "roles/container.developer",
    members: [gcpServiceAccount.email.apply(email => `serviceAccount:${email}`)]
});

// Grant the ServiceAccount admin permissions inside the Kubernetes cluster.
export const k8sRoleBinding = new k8s.rbac.v1.ClusterRoleBinding(
    "cluster-admin-binding",
    {
        metadata: { name: "cluster-admin-binding" },
        roleRef: {
            apiGroup: "<http://rbac.authorization.k8s.io|rbac.authorization.k8s.io>",
            kind: "ClusterRole",
            name: "cluster-admin"
        },
        subjects: [
            { apiGroup: "<http://rbac.authorization.k8s.io|rbac.authorization.k8s.io>", kind: "User", name: gcpServiceAccount.email }
        ]
    },
    { provider: k8sProvider }
);

export const clientSecret = gcpServiceAccountKey.privateKey.apply(key =>
    JSON.parse(Buffer.from(key, "base64").toString("ascii"))
);

then you can do something like:

pulumi stack output clientSecret > client-secret.json
gcloud auth activate-service-account --key-file client-secret.json

then you are auth’d as the service account in question.

This is how we do Travis integration: https://github.com/pulumi/pulumi-kubernetes/blob/master/.travis.yml#L9

I was trying to find out an

auth-provider

method inside the

kubeconfig

I would be able to configure inside pulumi with whatever is at my disposal to provide the right authentication in the

k8sProvider

so everything would run in one shot.

So, what you’re telling me is that it’s kind of impossible to do so, right ?

I’m saying that you have to bootstrap the roles from the CLI of someone who is an administrator.

So imagine your’e starting with nothing. Someone is an

owner

in the GCP account. How do you register service accounts and roles for the rest of your org?

The

owner

has to write a pulumi program with all that stuff, which bootstraps those roles.

Then, everyone else can deploy apps, infrastructure, etc.

OTOH, if that

owner

is deploying everything, from the infrastructure up, then you should have no problems because they are already the owner.

There is no escape from this generally: You have to create a GCP account, and then use that to grant access to everyone else. Then the stack outputs are consumed by other applications (e.g., CI) which allows you to deploy other things.

make sense?

Especially as you get more people using it.

You usually want kube app devs to write kube app dev code, vs having global access to your data storage facilities, etc.,

Some companies go so far as to have data storage facilities in a completely different AWS/GCP account

If you are

owner

you should have permission to do everything.

anyway, I think I can make something from all of that now, thanks for your time and help !

sure, we’ll have more stuff that provides guidance on this sort of thing soon.