This topic tells you how to set up developer namespaces by using the legacy manual process. For more information about how to automatically set up your developer namespaces, see Namespace Provisioner.
If you plan to install or have already installed Out of the Box Supply Chains with Testing and Scanning, you can use Namespace Provisioner to set up the required resources. For more information, see Customize installation in the Namespace Provisioner documentation for configuration steps.
You can choose either one of the following two approaches to create a Workload
for your application by using the registry credentials specified, add credentials and Role-Based Access Control (RBAC) rules to the namespace that you plan to create the Workload
in:
Run the following command to add secrets, a service account to execute the supply chain, and RBAC rules to authorize the service account to the developer namespace:
cat <<EOF | kubectl -n YOUR-NAMESPACE apply -f -
apiVersion: v1
kind: Secret
metadata:
name: tap-registry
annotations:
secretgen.carvel.dev/image-pull-secret: ""
type: kubernetes.io/dockerconfigjson
data:
.dockerconfigjson: e30K
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: default
secrets:
- name: registry-credentials
imagePullSecrets:
- name: registry-credentials
- name: tap-registry
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: default
rules:
- apiGroups: [source.toolkit.fluxcd.io]
resources: [gitrepositories]
verbs: ['*']
- apiGroups: [source.apps.tanzu.vmware.com]
resources: [imagerepositories]
verbs: ['*']
- apiGroups: [carto.run]
resources: [deliverables, runnables]
verbs: ['*']
- apiGroups: [kpack.io]
resources: [images]
verbs: ['*']
- apiGroups: [conventions.apps.tanzu.vmware.com]
resources: [podintents]
verbs: ['*']
- apiGroups: [""]
resources: ['configmaps']
verbs: ['*']
- apiGroups: [""]
resources: ['pods']
verbs: ['list']
- apiGroups: [tekton.dev]
resources: [taskruns, pipelineruns]
verbs: ['*']
- apiGroups: [tekton.dev]
resources: [pipelines]
verbs: ['list']
- apiGroups: [kappctrl.k14s.io]
resources: [apps]
verbs: ['*']
- apiGroups: [serving.knative.dev]
resources: ['services']
verbs: ['*']
- apiGroups: [servicebinding.io]
resources: ['servicebindings']
verbs: ['*']
- apiGroups: [services.apps.tanzu.vmware.com]
resources: ['resourceclaims']
verbs: ['*']
- apiGroups: [scanning.apps.tanzu.vmware.com]
resources: ['imagescans', 'sourcescans']
verbs: ['*']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: default
subjects:
- kind: ServiceAccount
name: default
Where YOUR-NAMESPACE
is your developer namespace.
Follow these steps to enable additional users by using Kubernetes RBAC to submit jobs to the Supply Chain:
Choose either of the following options to give developers namespace-level access and view access to appropriate cluster-level resources:
Option 1: Use the Tanzu Application Platform RBAC CLI plug-in (beta).
To use the tanzu rbac
plug-in to grant app-viewer
and app-editor
roles to an identity provider group, run:
tanzu rbac binding add -g GROUP-FOR-APP-VIEWER -n YOUR-NAMESPACE -r app-viewer
tanzu rbac binding add -g GROUP-FOR-APP-EDITOR -n YOUR-NAMESPACE -r app-editor
Where:
YOUR-NAMESPACE
is the name you give to the developer namespace.GROUP-FOR-APP-VIEWER
is the user group from the upstream identity provider that requires access to app-viewer
resources on the current namespace and cluster.GROUP-FOR-APP-EDITOR
is the user group from the upstream identity provider that requires access to app-editor
resources on the current namespace and cluster.For more information about tanzu rbac
, see Bind a user or group to a default role.
VMware recommends creating a user group in your identity provider’s grouping system for each developer namespace and then adding the users accordingly.
Depending on your identity provider, you might need to take further action to federate user groups appropriately with your cluster. For an example of how to set up Azure Active Directory (AD) with your cluster, see Integrating Azure Active Directory.
Option 2: Use the native Kubernetes YAML.
To apply the RBAC policy, run:
cat <<EOF | kubectl -n YOUR-NAMESPACE apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-permit-app-viewer
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: app-viewer
subjects:
- kind: Group
name: GROUP-FOR-APP-VIEWER
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: YOUR-NAMESPACE-permit-app-viewer
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: app-viewer-cluster-access
subjects:
- kind: Group
name: GROUP-FOR-APP-VIEWER
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-permit-app-editor
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: app-editor
subjects:
- kind: Group
name: GROUP-FOR-APP-EDITOR
apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: YOUR-NAMESPACE-permit-app-editor
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: app-editor-cluster-access
subjects:
- kind: Group
name: GROUP-FOR-APP-EDITOR
apiGroup: rbac.authorization.k8s.io
EOF
Where:
YOUR-NAMESPACE
is the name you give to the developer namespace.GROUP-FOR-APP-VIEWER
is the user group from the upstream identity provider that requires access to app-viewer
resources on the current namespace and cluster.GROUP-FOR-APP-EDITOR
is the user group from the upstream identity provider that requires access to app-editor
resources on the current namespace and cluster.VMware recommends creating a user group in your identity provider’s grouping system for each developer namespace and then adding the users accordingly.
Depending on your identity provider, you might need to take further action to federate user groups appropriately with your cluster. For an example of how to set up Azure Active Directory (AD) with your cluster, see Integrating Azure Active Directory.
Rather than granting roles directly to individuals, VMware recommends using your identity provider’s user groups system to grant access to a group of developers. For an example of how to set up Azure AD with your cluster, see Integrating Azure Active Directory.
(Optional) Log in as a non-admin user, such as a developer, to see the effects of RBAC after the bindings are applied.