support custom CA bundle for AWS API #372
Conversation
|
|
||
| // useCustomCABundle will set up a custom CA bundle in the AWS options if a CA bundle is configured in the | ||
| // kube cloud config. | ||
| func useCustomCABundle(awsOptions *session.Options, ctrlRuntimeClient client.Client) error { |
There was a problem hiding this comment.
Fetching this object each reconcile is a little spammy, but this allows users to potentially update the CA bundle day 2 (or whenever) and we don't need to worry about restarting our controller.
There was a problem hiding this comment.
The resource will be cached locally. The client will not have to reach out to the server on every reconcile.
There was a problem hiding this comment.
this makes sense to me, but i have a couple requests. could we add a unit test to ensure that the custom bundle logic doesn't break in the future?
i think it would be nice to document this as well, maybe a small section at the bottom of the readme about how to use a custom ca bundle? (or even just an example in the examples directory)
Yes.
In my opinion, knowledge about how to update the custom CA bundle does not need to live in the cluster-api-provider. The custom CA bundle is used globally in the cluster for all interactions with the AWS API. So it makes sense to me to document maintenance of it more globally as well. |
that makes good sense to me, thanks! edit: probably something we should document in the main machine-api-operator docs |
staebler
force-pushed
the
aws_c2s_support
branch
from
72bfaaf
to
66d416a
Compare
staebler
force-pushed
the
aws_c2s_support
branch
from
66d416a
to
0d62fc1
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: elmiko The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
the
approved
staebler
force-pushed
the
aws_c2s_support
branch
from
0d62fc1
to
f506e27
Compare
|
/retest |
|
/test unit |
|
@staebler it looks like we might have done something that is affecting the unit tests. the failure seems unrelated to your change, i'm looking into a fix now. |
|
seems like we do have a fix, it is in #332 |
|
/test unit |
1 similar comment
|
/test unit |
|
Is the "error: build error: error building at STEP "RUN umask 0002...--max-args 100 --no-run-if-empty chmod g+xw": exit status 1" message a flake? Searching chat history I see references to this resulting from cloning private repos. |
it looks like a flake, that isn't how the test was failing before. seems like that is happening during the test setup. |
It is just an artifact of the merge conflict, right? |
|
could be |
When a cluster is installed in a AWS C2S region, access to the AWS API requires a custom CA bundle for trust. The custom CA bundle is read from the "ca-bundle.pem" key of the kube-cloud-config ConfigMap in the openshift-config-managed namespace. https://issues.redhat.com/browse/CORS-1584
staebler
force-pushed
the
aws_c2s_support
branch
from
f506e27
to
e61b30e
Compare
|
Unit tests are passing now after the rebase. |
|
/lgtm |
When a cluster is installed in a AWS C2S region, access to the AWS API requires a custom CA bundle for trust. The custom CA bundle is read from the "ca-bundle.pem" key of the kube-cloud-config ConfigMap in the openshift-config-managed namespace.
https://issues.redhat.com/browse/CORS-1584