You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _data/snippets.yml
+17-3Lines changed: 17 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -72,6 +72,20 @@ concurrent_jobs: |
72
72
73
73
- if your build depends on an external resource and might run into a race
74
74
condition with concurrent jobs.
75
+
enabling_access_jobs_logs: |
76
+
This setting allows you to increase security by preventing access to old job logs older than 360 days. Or, in the case of a necessity, users can explicitly enable access to public and private old job log repositories.
77
+
78
+
The following are the available configurations:
79
+
* If this setting is ON, it enables access to build job logs older than 365 days.
80
+
* If this setting is OFF, access to build job logs older than 365 days is unavailable via UI or API calls.
81
+
limiting_access_jobs_logs: |
82
+
Similarly, this setting allows you to restrict access to build job logs for any user without write/push access rights to the repository. Limit job log visibility to only those that needed it. Enable this setting and ensure job logs are only available to users with respective read or write access to the individual repository.
83
+
84
+
The following are the available configurations:
85
+
* If this setting is ON, it allows access to build job logs only for users with write/push permissions to this repository. Limits access to build job logs via UI and API.
86
+
* If this setting is OFF, users with read access to the repository can access the build job logs.
87
+
88
+
Please note that the '*Limiting access to build job logs*' repository setting applies only to users with ‘write/push’ permissions.
75
89
auto_cancellation: |
76
90
If you are only interested in building the most recent commit on each branch you can use this new feature to automatically cancel older builds that are in the **queued** state and are not yet running.
For Git repositories, you may manage per repository how the [environment variables](/user/environment-variables/) and the [custom SSH keys](/user/private-dependencies/#user-key) will be handled in Travis CI when a build triggered as an effect of filing a Pull Request from a forked repository. Two settings are available specifically for this purpose, allowing you to customize your security vs. collaboration setup.
164
178
165
-
**base repository** - a Git repository, which is forked by someone else
166
-
**fork** or **forked repository** - any Git repository forked from the **base repository**
167
-
**PR** - Pull Request (e.g. in GitHub, BitBucket, GitLab) or Merge Request (in Assembla).
179
+
* **base repository** - a Git repository, which is forked by someone else
180
+
* **fork** or **forked repository** - any Git repository forked from the **base repository**
181
+
* **PR** - Pull Request (e.g. in GitHub, BitBucket, GitLab) or Merge Request (in Assembla)
168
182
169
183
> Please note: Repositories activated in [Travis CI](https://app.travis-ci.com ) before **March 1st, 2022** will have the `Share encrypted environment variables with forks (PRs) ` setting set to OFF. Please verify your collaboration model if necessary (especially for public repositories). The `Share SSH keys with forks (PRs)` will be set to ON for private repositories not to break too many collaboration setups.
170
184
Repository settings will be set by default to OFF for any repository activated in [Travis CI](https://app.travis-ci.com) after **March 1st, 2022**. For repositories activated in Travis CI after **March 1st, 2022**, you may want to consider changing the default settings depending on your collaboration model.
Copy file name to clipboardExpand all lines: user/best-practices-security.md
+40Lines changed: 40 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,6 +13,22 @@ Please make sure your secret is never related to the repository or branch name,
13
13
14
14
> The beta Windows support does not obfuscate secure environment variables leaked into the build log. Please keep reading the next section, [on how to avoid leaking secrets to build logs](https://docs.travis-ci.com/user/best-practices-security/#recommendations-on-how-to-avoid-leaking-secrets-to-build-logs)
15
15
16
+
### Log Scans
17
+
18
+
Travis CI has also enabled a mandatory post-job log scan in an attempt to find any other potential leakage of secrets. These scans are carried out on the the raw job log files shortly after the build job is completed. Scans are executed using [Trivy](https://github.com/aquasecurity/trivy) and [detect-secrets](https://github.com/Yelp/detect-secrets), Open Source scanners made available by their maintainers via means of a permissive OSS license. If the scanning process finds an unmasked secret-like entry in the job log, Travis CI, as a precautionary action, will mask the full line in the job log with asterisks (`*`) and produce a log scan report, available to the repository administrators for 7 days.
19
+
20
+
The job log scan report contains details on found potential secrets, referring to the line numbers in the **raw** job log file, and is meant to help review and find the source of the possible leak and if this proves to be an actual exposition of the secret, the scan fixes that.
21
+
22
+
When the additional post-job scanning process finds a potential leak in the build-job log, a graphical status in the Travis CI Web UI will present the log scan results. The *log scan: failing* is displayed over the repository page and in the dashboard for the next 7 days or until at least one of the repository administrators visits the job log scan report page, whichever condition is satisfied first.
23
+
24
+
Since the job log scan is executed by the tools looking for secret-like entries, the notifications must be treated as a warning about the **potential** issue and verified by the repository administrator. Therefore, we recommend the following verification steps:
25
+
26
+
* Reviewing the exact build instructions in the repository `.travis.yml` file (particularly if any unencrypted secrets are used) and build scripts called from within the `.travis.yml` recipe.
27
+
* Re-running suspicious jobs and reviewing the build job log on the go. Particularly around the preemptively censored area (please mind it will re-trigger the job log scan and any potential notifications in the process).
28
+
29
+
> Please note: The scan results may produce false positives and/or miss some items due to the nature of the scanners (searching for secret-like patterns). This is continuous work, and we expect it to improve over time based on findings and feedback. Also, we closely monitor the number of warnings raised by the job log scan process and decide later on to enable respective email notifications on top of existing visual indicators.
30
+
31
+
16
32
## Recommendations on how to avoid leaking secrets to build logs
17
33
Despite our best efforts, there are however many ways in which secure information can accidentally be exposed. These vary according to what tools you are using and what settings you have enabled. Some things to look out for are:
18
34
@@ -31,6 +47,30 @@ Preventing commands from displaying any output is one way to avoid accidentally
31
47
git push url-with-secret >/dev/null 2>&1
32
48
```
33
49
50
+
While using Travis CI, you may want to consider the additional means to decrease the risk of exposing secrets in the build job logs:
51
+
52
+
### Always use encrypted secrets
53
+
Travis CI offers the ability to either [encrypt your secret](/user/encryption-keys/) with the Travis-CLI (command line interface tool) or define the secret in the [Travis CI Repository Settings](/user/environment-variables/#defining-variables-in-repository-settings).
54
+
55
+
Shall the secret be stored in an encrypted file within your source code repository, you may instead [encrypt a file with a secret](/user/encrypting-files/) and use it during the build job. Decrypt your file for the shortest time needed and remove any temporary environment variables from the build job environment as soon as these are not necessary.
56
+
57
+
Please mind that at some point, the secret, in order to be used, must be decrypted for the build job environment. Thus debug outputs to the standard outputs may still result in secret exposure. The additional post-job log scanning process is meant to find these as much as possible.
58
+
59
+
### Use the Hashicorp Vault KMS integration
60
+
If you manage your secrets using the Hashicorp Vault KMS (Key Management System), then you may use the existing [Travis CI - Hashicorp integration](/user/hashicorp-vault-integration) to obtain secrets directly to the build job.
61
+
62
+
Again, please be wary of any possible debug outputs to the standard outputs in the build job environment. The additional post-job log scanning process is meant to find these as much as possible. The advantage of pulling the secret from a KMS managed by you is the ability to rotate it from a single secret repository in case of any incident. We strongly recommend using Hashicorp Vault credentials limited to a specific set of CI/CD-related secrets to limit the threat scope for the KMS.
63
+
64
+
### Limit access to the job logs
65
+
Review who and why should have access to the build job logs and set the appropriate options in the [Travis CI Repository Settings](/user/disable-job-logs/).
66
+
67
+
### Review the settings for builds triggered from forked Git repositories
68
+
Review the [Travis CI Repository Settings](/user/pull-requests#pull-requests-and-security-restrictions) and adjust what should be shared with forks. This is meant for a collaboration pattern when a forked repository can file a Pull Request to the base repository, thus triggering a CI/CD build job with automated build and tests as a part of the Pull Request validation and approval process. Assess the risks and adjust settings to your scenario.
69
+
70
+
### Run builds requiring secrets in private repositories
71
+
If this is a viable option, consider running builds requiring the usage of secrets as a CI/CD for private repositories with a carefully reviewed collaborator list. Combined with the above options, it should decrease the risk of secret exposition in the build job log.
72
+
73
+
34
74
## If you think that you might have exposed secure information
35
75
36
76
As an initial step, it’s possible to delete logs containing any secure information by clicking the *Remove log* button on the build log page of Travis CI.
Copy file name to clipboardExpand all lines: user/build-config-imports.md
+33-1Lines changed: 33 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -218,6 +218,23 @@ import:
218
218
```
219
219
{: data-file=".travis.yml"}
220
220
221
+
This mode first merges your `.travis.yml` contents into the `one.yml` file (i.e., items in the .travis.yml file “win”, if the merge mode deep_merge would be used and will overwrite keys on respective levels in `one.yml`).
222
+
223
+
Respectively:
224
+
225
+
```yaml
226
+
import:
227
+
- source: one.yml
228
+
mode: deep_merge # deep merge
229
+
- source: two.yml
230
+
mode: deep_merge # deep merge
231
+
```
232
+
{: data-file=".travis.yml"}
233
+
234
+
This mode first merges your `.travis.yml` contents into the `one.yml` file (overwriting, if required, sections in `one.yml` with content from `.travis.yml`). The results are merged into the `two.yml` file (again, items in the result of the previous merge win over what’s in this one, as the `deep_merge` mode is specified here).
235
+
236
+
The reasoning behind this is that in many cases when you import something to your `.travis.yml’ file, you want to be able to overwrite or customize that imported configuration with config in your `.travis.yml` file.
237
+
221
238
### Merge
222
239
223
240
The merge mode `merge` performs a shallow merge.
@@ -239,4 +256,19 @@ When triggering a build through the Travis API or the web UI, the order of ascen
239
256
- Config from the API build request payload, if given
240
257
- Imported configs from the API build request payload, if given, in the order listed (following a depth-first search pattern in case those imported configs import other configs)
241
258
- Config from `.travis.yml`
242
-
- Imported configs from `.travis.yml`, in the order listed (following a depth-first search pattern in case those imported configs import other configs)
259
+
- Imported configs from `.travis.yml`, in the order listed (following a depth-first search pattern in case those imported configs import other configs).
260
+
261
+
## FAQ
262
+
263
+
### Can I import a shared build config at a specific job level?
264
+
265
+
No. The parsed YAML trees must be merged. Thus, the `import` keyword is accepted only at the root level. If it suits your scenario, you can specify your job template in, e.g., `job.yml` and import it into your `.travis.yml` with the `mode: deep_merge`, adding in the `.travis,yml` specifics to be overridden in the imported template.
266
+
267
+
### Is it possible to create and use anchors via the shared configs mechanism?
268
+
269
+
Unfortunately, it’s not supported.
270
+
As much as we encourage [using YAML as a build configuration language](/user/build-config-yaml), anchors and aliases, referring to these anchors must be defined and used within a single `.yml` file and will be expanded before any *import* action (merging parse trees) occurs. For the same reason, attempts to assign an anchor within `.travis.yml` to an *imported* key will not work — both `.travis.yml` and `imported.yml` must be parsed before the merge action can occur.
271
+
272
+
See also *native-api* concise [explanation in the Community Forum](https://travis-ci.community/t/imported-anchors-not-working/10035/2)
Copy file name to clipboardExpand all lines: user/conditional-builds-stages-jobs.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,6 +11,8 @@ You can find more information on the build config format in our [Travis CI Build
11
11
12
12
You can configure Travis CI to only run builds when certain conditions are met. Any builds that do not meet these conditions are listed in the *Requests* tab of your repository, even though the actual build is not generated.
13
13
14
+
> Travis CI’s system fetches and processes the .travis.yml config file from the repository and the branch explicitly specified in the build request
15
+
14
16
For example, this allows builds only to run on the `master` branch:
0 commit comments