WARNING: Jenkins X version 2.x is deprecated.
Please refer to the v3 documentation for the latest supported version.
Required cloud resources
No matter which Terraform module you choose, each will create a similar set of resources. Most importantly it will create the Kubernetes cluster of course, but there are a other aspects as well.
Terraform enables all required cloud provider APIs.
Logs, test reports and build artifacts, but also backups and secrets are stored in cloud storage (buckets). One task of the Terraform module is to create these buckets. Some buckets are optional and you can configure whether they get created or not. Refer to the documentation for your cloud provider specific Terraform module for more information.
If all storage options are enabled, the following buckets are created:
- Log bucket
- Bucket for storing build logs. Refer to Configuring Storage for more information.
- Report bucket
- Bucket for storing test and coverage reports. Refer to Configuring Storage for more information.
- Repository bucket
- Bucket used for storing artifacts when using Bucketrepo. Bucketrepo is a small footprint microservice that is an alternative to both Nexus and Chartmusem.
- Velero bucket
- Bucket for Velero backups.
- Vault bucket
- Bucket used by Vault for storing its data. Jenkins X uses Vault to store secrets. Refer to Vault for more information.
Several Jenkins X services need to interact with the underlying cloud infrastructure. For example, the Build Controller needs to be able to store log files into the log storage bucket. Another example is ExternalDNS creating dynamically new DNS entries for services. In this case ExternalDNS service needs access to the DNS APIs of the underyling cloud provider.
To ensure that each service gets only the permissions it needs to fulfill its responsibilty, cloud providers allow to bind Kubernetes service accounts to cloud provider specific service announts or roles. The mechanism to achieve this varies between cloud providers. For Google Cloud it is called Workload Identity and for AWS IAM Roles for Service Accounts. It is the resposibilty of the corresponding Terraform module to configure these permissions.
At the moment Kubernetes service accounts for the following areas are created:
- Service account used by Tekton for the actual pipeline execution. The Tekton service account needs permissions to read and write to cloud storage. The name of the service account is tekton-bot.
- Build Controller
- Service account used by the Build Controller service which is responsible to track the overall progress of pipeline executions. The Build Controller service account needs permissions to read and write to cloud storage. The name of the service account is jenkins-x-controllerbuild.
- There are three Kubernetes services accounts created related to DNS. One for ExternalDNS with the name exdns-external-dns and two for cert-manager, namely cm-cert-manager and cm-cainjector. Each of these services need access to the DNS API of the cloud provider.
- Service account used by the Vault operator. The Vault service account needs permissions to read and write to cloud storage and access to kryptographic key managment. The name of the service account is _<cluster-name>-vt.
- Service account used by the Velero backup service. The Velero service account needs permissions to read and write to cloud storage. The name of the service account is velero-server
- Service account used by Kaniko which is a safer option to build Docker images in Kubernetes than the Docker daemon. The Kaniko service account needs permissions to read and write to cloud storage. The name of the service account is kaniko-sa.
Cryptographic key management
For using the Vault Operator, the Terraform module needs to create a cryptographic keyring and key to seed Vault.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.