arch: add adr on autopilot basic auth + oras support #4524
Conversation
ricardomaraschini
force-pushed
the
oras-plus-basic-auth-adr
branch
3 times, most recently
from
b29ce58
to
5f0ae66
Compare
|
@ricardomaraschini you're missing sign-off for the commits |
| } | ||
| ``` | ||
|
|
||
| The secret pointed to by the provided `ArtifactPullSecret` property is expected to by of type `kubernetes.io/dockerconfigjson` if the protocol in use is `oci://` (see below) or of type `kubernetes.io/basic-auth` if protocols `http://` or `https://` are used . |
There was a problem hiding this comment.
Why only basic auth? If we'd have the full Authorization header value as a secret we'd be supporting basically everything, right?
There was a problem hiding this comment.
I was attempting to use only known secret types and there isn't one regarding a different kind of authentication.
It does not mean we can't introduce our Opaque thingy though.
There was a problem hiding this comment.
I can change this proposal and add that if the secret contains an authorization entry we will send its content in the Authorization http header. What do you think ?
There was a problem hiding this comment.
I think I followed you. Let me know what you think of the updated proposal.
ricardomaraschini
force-pushed
the
oras-plus-basic-auth-adr
branch
2 times, most recently
from
89da778
to
82530a3
Compare
| // ArtifactPullSecrets holds a reference to a secret where Docker or Basic Auth | ||
| // credentials are stored. We use these credentials when pulling the artifacts from | ||
| // the URL. | ||
| ArtifactPullSecret *ArtifactPullSecret `json:"artifactPullSecret,omitempty"` |
There was a problem hiding this comment.
Am I assuming correct that his would then apply to the existing http protocol too? If so, maybe write it up a bit
There was a problem hiding this comment.
Yes, you are correct. This is the change I have introduced, let me know if it suffices: 89335cb
| // ArtifactPullSecrets holds a reference to a secret where the credentials are | ||
| // stored. We use these credentials when pulling the artifacts from the provided | ||
| // URL using any of the supported protocols (http, https, and oci). | ||
| ArtifactPullSecret *ArtifactPullSecret `json:"artifactPullSecret,omitempty"` |
There was a problem hiding this comment.
Comparing this to e.g. ImagePullSecrets. There, it's an array. Would it make sense to use an array here, as well?
| ArtifactPullSecret *ArtifactPullSecret `json:"artifactPullSecret,omitempty"` | |
| ArtifactPullSecrets []ArtifactPullSecret `json:"artifactPullSecrets,omitempty"` |
There was a problem hiding this comment.
Which secret would we use for basic and token based authentications ?
|
|
||
| No other property will be parsed and used. For sake of defining the expected behaviour in case of conflicting configurations: | ||
|
|
||
| > In the case where the three properties are set (`username`, `password`, and `authorization`) Autopilot will ignore `username` and `password`, i.e. `authorization` takes precedence over username and password. |
There was a problem hiding this comment.
What about using proper secret types for that, so there's no ambiguities?
There's already the well-defined Basic authentication Secret type. I'd just use that. We could add some k0s-specifc types, say auth.k0s.k0sproject.io/bearer-token (desugars into Authorization: Bearer ${data.token}) or auth.k0s.k0sproject.io/http-authorization-header (desugars into Authorization: ${data.authorization}).
There was a problem hiding this comment.
My initial proposal was to use the Basic Authentication secret type, I diverted from it because someone mentioned it would be nice to support token based authentications as well.
In your opinion, what would be the advantage of defining two other types of Secrets on this specific case ?
I mean, one could define an Opaque secret with authorization: "Bearer abc123" while other could define it as authorization: "abc123" and we would have the same behaviour you described above, no ?
There was a problem hiding this comment.
Yeah, in case of using the authorization header, it'd be easy enough for users to prefix their headers, if needed. There might still be some value in having a secret containing the "pure" credentials only, as the Bearer prefix is already protocol specific. If you want to use the same secret in other contexts, you'd maybe need to strip the "Bearer " prefix again before you can use it. Anyhow, only having one secret type for the header would be enough for now.
I'd really like to avoid the use of opaque secrets, as we then need to define which secret fields take precedence over others. Requiring explicit types from the beginning makes it much easier to add other auth types (e.g. for #4524 (comment)) in the future without having to implement, document and remember all the fallback rules.
| When it comes to the `Opaque` secret layout (used for HTTP requests) Autopilot will accept the following entries: | ||
|
|
||
| - `username` and `password`: if both are set then Autopilot will attempt to pull the artifacts using [Basic Authentication](https://www.ibm.com/docs/en/cics-ts/6.1?topic=concepts-http-basic-authentication). | ||
| - `authorization`: if this property is set then the `Authorization` [header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization) will be set to its value when pulling the artifacts. |
There was a problem hiding this comment.
Is there any possibility, that different registries might use different headers, e.g. X-Auth-Token, X-Access-Token, etc.? Or accept some additional headers?
Maybe we can have a secret type, that will put all the secret content directly into headers without any processing.
There was a problem hiding this comment.
In my opinion we don't need to worry about this for registry access. Registries, more or less, work in the same way and we have implementation of registry clients for go. The authorization property here will be used only for HTTP or HTTPS requests.
ricardomaraschini
force-pushed
the
oras-plus-basic-auth-adr
branch
from
b30b295
to
6319764
Compare
|
The PR is marked as stale since no activity has been recorded in 30 days |
|
Can we somehow expedite this ? I can see that the automation is already tired of the silence here :-) I think I have already addressed all comments. |
|
|
||
| No other property will be parsed and used. For sake of defining the expected behaviour in case of conflicting configurations: | ||
|
|
||
| > In the case where the three properties are set (`username`, `password`, and `authorization`) Autopilot will ignore `username` and `password`, i.e. `authorization` takes precedence over username and password. |
There was a problem hiding this comment.
Yeah, in case of using the authorization header, it'd be easy enough for users to prefix their headers, if needed. There might still be some value in having a secret containing the "pure" credentials only, as the Bearer prefix is already protocol specific. If you want to use the same secret in other contexts, you'd maybe need to strip the "Bearer " prefix again before you can use it. Anyhow, only having one secret type for the header would be enough for now.
I'd really like to avoid the use of opaque secrets, as we then need to define which secret fields take precedence over others. Requiring explicit types from the beginning makes it much easier to add other auth types (e.g. for #4524 (comment)) in the future without having to implement, document and remember all the fallback rules.
adds an adr on adding oras and basic auth support on autopilot. Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
addressing some issues reported on the adr. Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
as per pr comments it would be nice to also support the authorization header. this commit covers this possibility to the adr. Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
be more explicit by mentioning the secret may be used for http as well as for oci artifacts retrieval. Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
use InsecureSkipTLSVerify instead. Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
use an existing type instead of definining a new one. Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
ricardomaraschini
force-pushed
the
oras-plus-basic-auth-adr
branch
from
fb9f7f8
to
fff4dcc
Compare
as per pr review comment. Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
remove some dangling references to the old artifactPullSecret field. Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
if no protocol is provided (http, https, or oci) or if an invalid one is provided an error should be signalled on the plan object. Signed-off-by: Ricardo Maraschini <ricardo.maraschini@gmail.com>
There was a problem hiding this comment.
@ricardomaraschini I see all the comments are resolved so I'm stamping this 👍 Thanks for your patience 😄
We can iron out the remaining details during implementation and update the ADR if needed.
Description
this pr adds an architecture decision record on adding oras and basic auth support on autopilot.
Type of change
How Has This Been Tested?
Checklist: