bvahdat opened a new issue, #6869:
URL: https://github.com/apache/camel-k/issues/6869
### Requirement
### Description
The `gitops` trait authenticates against the Git server with HTTP basic
auth, using the token from `gitops.secret` as password and a **hardcoded
username `camel-k`**:
- `pkg/trait/gitops.go` (push):
```go
Auth: &http.BasicAuth{
Username: "camel-k",
Password: token,
},
```
- `pkg/util/gitops/gitops.go`, `CloneGitProject` (clone):
```go
gitCloneOptions.Auth = &http.BasicAuth{
Username: "camel-k", // yes, this can be anything except an empty
string
Password: secretToken,
}
```
The comment holds for GitHub, which ignores the username when a token is
used. **It does not hold for Bitbucket Cloud**: repository, project and
workspace access tokens only work with the username `x-token-auth` (see
https://support.atlassian.com/bitbucket-cloud/docs/using-access-tokens/). With
any other username Bitbucket rejects the request, so the `gitops` trait cannot
clone or push to a Bitbucket repository at all.
`gitops.committerName` / `gitops.committerEmail` do not help here - they
only set the commit author, not the authentication username.
### Steps to reproduce
1. Create a Bitbucket Cloud repository access token with *Repositories: Read
and Write*.
2. Verify the token outside of Camel K:
```bash
git ls-remote
https://x-token-auth:[email protected]/<workspace>/<repo>.git # works
git ls-remote https://camel-k:[email protected]/<workspace>/<repo>.git
# authentication fails
```
3. Store the token in a secret, reference it in `gitops.secret`, enable the
`gitops` trait with `gitops.url` pointing to that repository and build an
Integration: the push after the build fails, because the operator always
authenticates as `camel-k`.
### Expected behaviour
The username used for Git authentication can be configured, so the trait
works with Git servers that validate it (Bitbucket Cloud: `x-token-auth`).
### Proposal
Either (or both) of:
1. **A new trait property** `gitops.username`, default `camel-k` (fully
backward compatible), used for both clone and push:
```yaml
traits:
gitops:
enabled: true
url: https://bitbucket.org/<workspace>/<repo>.git
secret: my-git-token
username: x-token-auth
```
2. **Support secrets of type `kubernetes.io/basic-auth`** in
`gitops.secret`: if the secret has a `username` key, use it together with
`password`; otherwise keep today's behaviour (first key = token, username
`camel-k`). Today `GitToken` picks "the first key" of the secret, which with
several keys depends on map iteration order - an explicit format would also
make that deterministic.
### Environment
- Camel K 2.11.0 (operator and `kamel` CLI); the username is still hardcoded
on `main`
- Git server: Bitbucket Cloud, repository access token over HTTPS
### Workaround
None within the trait. We currently write the same promotion layout
(`manifests/promoted/<integration>/base` + overlays, image pinned by digest,
`jvm.classpath`, `camel.runtimeVersion`) with a script and push it ourselves.
I am happy to provide a PR for option 1.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
