MCO-1202: MCO-1203: MCO-1204: MCO-1205: MCO-1213: Implementing tlsSecurityProfile for MCO by djoshy · Pull Request #4435 · openshift/machine-config-operator

djoshy · 2024-06-25T20:22:34Z

- What I did

In regular cluster operation:

The operator and controller will listen on an APIServer object, which contains the global cluster tls settings.
The operator will now render TLSMinVersion and TLSCiphers to the MCC and MCD kube-rbac-proxy sidecar manifests via templated arguments.
The template controller will now render TLSMinVersion and TLSCiphers to the kube-rbac-proxy-crio metrics pods via templated arguments. These are per node pods in the MCO namespace, and deployed via MachineConfigs. As a result changing the tls settings will cause a MachineConfig rollout.
The MCS container now has two new TLS arguments. The operator will render TLSMinVersion and TLSCiphers via these new arguments in the MCS daemonset manifest. The MCS will attempt to create a http server with these new TLS settings while starting up.

During cluster bootstrap:

The bootstrap MCC will default to the intermediate security profile, unless an install time APIServer manifest is provided. This is necessary during bootstrap, as the kube-rbac-proxy-crio pod manifests show up in rendered MachineConfigs and we need the bootstrap MachineConfigs to match the in cluster MachineConfigs post install.
The bootstrap MCC has access to all install time manifests provided to the installer, but the bootstrap MCS does not. When the bootstrap MCC determines that an APIServer manifest has been provided, it will write it to bootstrap MCS's directory.
The bootstrap MCS will now read in the APIServer manifest and launch its http server with the TLS settings defined in the manifest. If no manifest is provided, it will default to the intermediate security profile.

- How to verify it

Bring up a cluster with an install time APIServer manifest named "cluster". To test bootstrap behavior, ensure
environment variable OPENSHIFT_INSTALL_PRESERVE_BOOTSTRAP is set to true.
Once the install is complete, observe the kube rbac proxy manifests in cluster to ensure they have the correct TLS configuration. These can be seen as arguments for the kube rbac proxy sidecards on the MCO deployments, as well as encapsulated in MachineConfigs for the kube-rbac-proxy-crio pods.
The MCS daemonset will log the current TLS settings at startup. You can also test the MCS endpoint using the method described in this comment.
You can also log in to the bootstrap node and verify that the MCS bootstrap logs started with the correct TLS settings.
Switch between TLS profiles by following the documentation.
This will cause a new MachineConfig rollout and also cause the MCC, MCD and MCS pods to restart. You can verify (2) and (3) is as expected as the update rolls through the cluster.

Things to note:

It may take a few moments before the operator rolls out the new manifests. If it is done while the MCO is doing a MachineConfig update to the master pool, the manifests won't be updated until the master pool is finished updating. This is because of the way the operator's sync loops are structured.
The APIServer rejects the Modern profile at the moment, according to the docs.
If no tlsSecurityProfile is provided, the MCO will default to Intermediate.

openshift-ci · 2024-06-25T20:23:55Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

openshift-ci-robot · 2024-06-26T20:14:27Z

@djoshy: This pull request references MCO-1202 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

- What I did

- How to verify it

- Description for the changelog

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2024-06-26T20:31:03Z

@djoshy: This pull request references MCO-1202 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

- What I did

Fetch global tlsSecurityProfile from the APIServer object

Render TLSMinVersion and TLSCiphers to MCC and MCD kube-rbac-proxy sidecar manifests via updated templates

Render TLSMinVersion and TLSCiphers to MCS daemonset manifest via updated templates

The MCS will attempt to create a http server with these new TLS settings while starting up. During bootstrap, the MCS will default to the intermediate security profile.

- How to verify it

Switch between TLS profiles by following the documentation.

Test the MCS endpoint using the method described in this comment.

The endpoint should switch between the ciphers and TLSMinVersion as you switch between Intermediate and Old. Note: The APIServer rejects the Modern profile at the moment. Please note that it may also take a few moments before the operator rolls out the new manifests. If it is done while the MCO is mid-upgrade, the manifests won't be updated until the master pool is finished updating.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

djoshy · 2024-06-27T12:58:18Z

/test e2e-hypershift
/test e2e-gcp-op-techpreview

openshift-ci-robot · 2024-06-28T15:17:38Z

@djoshy: This pull request references MCO-1202 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

- What I did

In regular cluster operation:

The operator and controller will listen on an APIServer object, which contain the global cluster tls settings.

The operator will render TLSMinVersion and TLSCiphers to MCC and MCD kube-rbac-proxy sidecar manifests via templated arguments.

The template controller will render TLSMinVersion and TLSCiphers to kube-rbac-proxy-crio metrics pods via templated arguments. These are per node pods in the MCO namespace, and deployed via MachineConfigs. As a result changing the tls settings will cause a MachineConfig rollout.

Added new TLS arguments for the MCS container. The operator will render TLSMinVersion and TLSCiphers via these new arguments in the MCS daemonset manifest. The MCS will attempt to create a http server with these new TLS settings while starting up.

During cluster bootstrap:

The MCC will default to the intermediate security profile, unless an install time APIServer manifest is provided. This is necessary as the kube-rbac-proxy-crio pod manifests show up in rendered MachineConfigs and we need the bootstrap MachineConfigs to match the in cluster MachineConfigs post install.

The MCS will default to the intermediate security profile. I plan to make this capable of reading the install time APIServer manifest too, but it does not cause a MachineConfig update, so it does not need to be solved within this PR.

- How to verify it

Bring up a cluster with an install time APIServer manifest named "cluster".

Once the install is complete, observe the kube rbac proxy manifests in cluster to ensure they have the correct TLS configuration.

The MCS daemonset will log the current TLS settings at startup. You can also test the MCS endpoint using the method described in this comment.

Switch between TLS profiles by following the documentation.

This will cause a new MachineConfig rollout and also cause the MCD/MCS pods to restart. You can verify (2) and (3) is as expected as the update rolls through the cluster.

Things to note:

It may take a few moments before the operator rolls out the new manifests. If it is done while the MCO is doing a MachineConfig update to the master pool, the manifests won't be updated until the master pool is finished updating. This is because of the way the operator's sync loops are structured.

The APIServer rejects the Modern profile at the moment, according to the docs.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2024-06-28T15:18:48Z

@djoshy: This pull request references MCO-1202 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

- What I did

In regular cluster operation:

The operator and controller will listen on an APIServer object, which contain the global cluster tls settings.

The operator will render TLSMinVersion and TLSCiphers to MCC and MCD kube-rbac-proxy sidecar manifests via templated arguments.

The template controller will render TLSMinVersion and TLSCiphers to kube-rbac-proxy-crio metrics pods via templated arguments. These are per node pods in the MCO namespace, and deployed via MachineConfigs. As a result changing the tls settings will cause a MachineConfig rollout.

Added new TLS arguments for the MCS container. The operator will render TLSMinVersion and TLSCiphers via these new arguments in the MCS daemonset manifest. The MCS will attempt to create a http server with these new TLS settings while starting up.

During cluster bootstrap:

The MCC will default to the intermediate security profile, unless an install time APIServer manifest is provided. This is necessary during bootstrap, as the kube-rbac-proxy-crio pod manifests show up in rendered MachineConfigs and we need the bootstrap MachineConfigs to match the in cluster MachineConfigs post install.

The MCS will default to the intermediate security profile. I plan to make this capable of reading the install time APIServer manifest too, but it does not cause a MachineConfig update, so it does not need to be solved within this PR.

- How to verify it

Bring up a cluster with an install time APIServer manifest named "cluster".

Once the install is complete, observe the kube rbac proxy manifests in cluster to ensure they have the correct TLS configuration.

The MCS daemonset will log the current TLS settings at startup. You can also test the MCS endpoint using the method described in this comment.

Switch between TLS profiles by following the documentation.

This will cause a new MachineConfig rollout and also cause the MCD/MCS pods to restart. You can verify (2) and (3) is as expected as the update rolls through the cluster.

Things to note:

It may take a few moments before the operator rolls out the new manifests. If it is done while the MCO is doing a MachineConfig update to the master pool, the manifests won't be updated until the master pool is finished updating. This is because of the way the operator's sync loops are structured.

The APIServer rejects the Modern profile at the moment, according to the docs.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2024-06-29T11:35:59Z

@djoshy: This pull request references MCO-1202 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

- What I did

In regular cluster operation:

The operator and controller will listen on an APIServer object, which contains the global cluster tls settings.

The operator will now render TLSMinVersion and TLSCiphers to the MCC and MCD kube-rbac-proxy sidecar manifests via templated arguments.

The template controller will now render TLSMinVersion and TLSCiphers to the kube-rbac-proxy-crio metrics pods via templated arguments. These are per node pods in the MCO namespace, and deployed via MachineConfigs. As a result changing the tls settings will cause a MachineConfig rollout.

The MCS container now has two new TLS arguments. The operator will render TLSMinVersion and TLSCiphers via these new arguments in the MCS daemonset manifest. The MCS will attempt to create a http server with these new TLS settings while starting up.

During cluster bootstrap:

The MCC will default to the intermediate security profile, unless an install time APIServer manifest is provided. This is necessary during bootstrap, as the kube-rbac-proxy-crio pod manifests show up in rendered MachineConfigs and we need the bootstrap MachineConfigs to match the in cluster MachineConfigs post install.

The MCS will default to the intermediate security profile. I plan to make this capable of reading the install time APIServer manifest too, but it does not cause a MachineConfig update, so it does not need to be solved within this PR.

- How to verify it

Bring up a cluster with an install time APIServer manifest named "cluster".

Once the install is complete, observe the kube rbac proxy manifests in cluster to ensure they have the correct TLS configuration.

The MCS daemonset will log the current TLS settings at startup. You can also test the MCS endpoint using the method described in this comment.

Switch between TLS profiles by following the documentation.

This will cause a new MachineConfig rollout and also cause the MCC, MCD and MCS pods to restart. You can verify (2) and (3) is as expected as the update rolls through the cluster.

Things to note:

It may take a few moments before the operator rolls out the new manifests. If it is done while the MCO is doing a MachineConfig update to the master pool, the manifests won't be updated until the master pool is finished updating. This is because of the way the operator's sync loops are structured.

The APIServer rejects the Modern profile at the moment, according to the docs.

If no tlsSecurityProfile is provided, the MCO will default to Intermediate.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2024-07-02T20:53:28Z

@djoshy: This pull request references MCO-1202 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

- What I did

In regular cluster operation:

The operator and controller will listen on an APIServer object, which contains the global cluster tls settings.

The operator will now render TLSMinVersion and TLSCiphers to the MCC and MCD kube-rbac-proxy sidecar manifests via templated arguments.

The template controller will now render TLSMinVersion and TLSCiphers to the kube-rbac-proxy-crio metrics pods via templated arguments. These are per node pods in the MCO namespace, and deployed via MachineConfigs. As a result changing the tls settings will cause a MachineConfig rollout.

The MCS container now has two new TLS arguments. The operator will render TLSMinVersion and TLSCiphers via these new arguments in the MCS daemonset manifest. The MCS will attempt to create a http server with these new TLS settings while starting up.

During cluster bootstrap:

The bootstrap MCC will default to the intermediate security profile, unless an install time APIServer manifest is provided. This is necessary during bootstrap, as the kube-rbac-proxy-crio pod manifests show up in rendered MachineConfigs and we need the bootstrap MachineConfigs to match the in cluster MachineConfigs post install.

The bootstrap MCC has access to all install time manifests provided to the installer, but the bootstrap MCC does not. When the bootstrap MCC determines that an APIServer manifest has been provided, it will write it to bootstrap MCS's directory.

The bootstrap MCS will now read in the APIServer manifest and launch its http server with the TLS settings defined in the manifest. If no manifest is provided, it will default to the intermediate security profile.

- How to verify it

Bring up a cluster with an install time APIServer manifest named "cluster". To test bootstrap behavior, ensure
environment variable OPENSHIFT_INSTALL_PRESERVE_BOOTSTRAP is set to true.

Once the install is complete, observe the kube rbac proxy manifests in cluster to ensure they have the correct TLS configuration. These can be seen as arguments for the kube rbac proxy sidecards on the MCO deployments, as well as encapsulated in MachineConfigs for the kube-rbac-proxy-crio pods.

The MCS daemonset will log the current TLS settings at startup. You can also test the MCS endpoint using the method described in this comment.

You can also log in to the bootstrap node and verify that the MCS bootstrap logs started with the correct TLS settings.

Switch between TLS profiles by following the documentation.

This will cause a new MachineConfig rollout and also cause the MCC, MCD and MCS pods to restart. You can verify (2) and (3) is as expected as the update rolls through the cluster.

Things to note:

It may take a few moments before the operator rolls out the new manifests. If it is done while the MCO is doing a MachineConfig update to the master pool, the manifests won't be updated until the master pool is finished updating. This is because of the way the operator's sync loops are structured.

The APIServer rejects the Modern profile at the moment, according to the docs.

If no tlsSecurityProfile is provided, the MCO will default to Intermediate.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

openshift-ci-robot · 2024-07-02T20:56:14Z

@djoshy: This pull request references MCO-1202 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

- What I did

In regular cluster operation:

The operator and controller will listen on an APIServer object, which contains the global cluster tls settings.

The operator will now render TLSMinVersion and TLSCiphers to the MCC and MCD kube-rbac-proxy sidecar manifests via templated arguments.

The template controller will now render TLSMinVersion and TLSCiphers to the kube-rbac-proxy-crio metrics pods via templated arguments. These are per node pods in the MCO namespace, and deployed via MachineConfigs. As a result changing the tls settings will cause a MachineConfig rollout.

The MCS container now has two new TLS arguments. The operator will render TLSMinVersion and TLSCiphers via these new arguments in the MCS daemonset manifest. The MCS will attempt to create a http server with these new TLS settings while starting up.

During cluster bootstrap:

The bootstrap MCC will default to the intermediate security profile, unless an install time APIServer manifest is provided. This is necessary during bootstrap, as the kube-rbac-proxy-crio pod manifests show up in rendered MachineConfigs and we need the bootstrap MachineConfigs to match the in cluster MachineConfigs post install.

The bootstrap MCC has access to all install time manifests provided to the installer, but the bootstrap MCC does not. When the bootstrap MCC determines that an APIServer manifest has been provided, it will write it to bootstrap MCS's directory.

The bootstrap MCS will now read in the APIServer manifest and launch its http server with the TLS settings defined in the manifest. If no manifest is provided, it will default to the intermediate security profile.

- How to verify it

Bring up a cluster with an install time APIServer manifest named "cluster". To test bootstrap behavior, ensure
environment variable OPENSHIFT_INSTALL_PRESERVE_BOOTSTRAP is set to true.

Once the install is complete, observe the kube rbac proxy manifests in cluster to ensure they have the correct TLS configuration. These can be seen as arguments for the kube rbac proxy sidecards on the MCO deployments, as well as encapsulated in MachineConfigs for the kube-rbac-proxy-crio pods.

The MCS daemonset will log the current TLS settings at startup. You can also test the MCS endpoint using the method described in this comment.

You can also log in to the bootstrap node and verify that the MCS bootstrap logs started with the correct TLS settings.

Switch between TLS profiles by following the documentation.

This will cause a new MachineConfig rollout and also cause the MCC, MCD and MCS pods to restart. You can verify (2) and (3) is as expected as the update rolls through the cluster.

Things to note:

It may take a few moments before the operator rolls out the new manifests. If it is done while the MCO is doing a MachineConfig update to the master pool, the manifests won't be updated until the master pool is finished updating. This is because of the way the operator's sync loops are structured.

The APIServer rejects the Modern profile at the moment, according to the docs.

If no tlsSecurityProfile is provided, the MCO will default to Intermediate.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

djoshy · 2024-07-03T12:15:18Z

/retest

openshift-ci-robot · 2024-07-03T15:45:26Z

@djoshy: This pull request references MCO-1202 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.17.0" version, but no target version was set.

Details

In response to this:

- What I did

In regular cluster operation:

The operator and controller will listen on an APIServer object, which contains the global cluster tls settings.

The operator will now render TLSMinVersion and TLSCiphers to the MCC and MCD kube-rbac-proxy sidecar manifests via templated arguments.

The template controller will now render TLSMinVersion and TLSCiphers to the kube-rbac-proxy-crio metrics pods via templated arguments. These are per node pods in the MCO namespace, and deployed via MachineConfigs. As a result changing the tls settings will cause a MachineConfig rollout.

The MCS container now has two new TLS arguments. The operator will render TLSMinVersion and TLSCiphers via these new arguments in the MCS daemonset manifest. The MCS will attempt to create a http server with these new TLS settings while starting up.

During cluster bootstrap:

The bootstrap MCC will default to the intermediate security profile, unless an install time APIServer manifest is provided. This is necessary during bootstrap, as the kube-rbac-proxy-crio pod manifests show up in rendered MachineConfigs and we need the bootstrap MachineConfigs to match the in cluster MachineConfigs post install.

The bootstrap MCC has access to all install time manifests provided to the installer, but the bootstrap MCS does not. When the bootstrap MCC determines that an APIServer manifest has been provided, it will write it to bootstrap MCS's directory.

The bootstrap MCS will now read in the APIServer manifest and launch its http server with the TLS settings defined in the manifest. If no manifest is provided, it will default to the intermediate security profile.

- How to verify it

Bring up a cluster with an install time APIServer manifest named "cluster". To test bootstrap behavior, ensure
environment variable OPENSHIFT_INSTALL_PRESERVE_BOOTSTRAP is set to true.

Once the install is complete, observe the kube rbac proxy manifests in cluster to ensure they have the correct TLS configuration. These can be seen as arguments for the kube rbac proxy sidecards on the MCO deployments, as well as encapsulated in MachineConfigs for the kube-rbac-proxy-crio pods.

The MCS daemonset will log the current TLS settings at startup. You can also test the MCS endpoint using the method described in this comment.

You can also log in to the bootstrap node and verify that the MCS bootstrap logs started with the correct TLS settings.

Switch between TLS profiles by following the documentation.

This will cause a new MachineConfig rollout and also cause the MCC, MCD and MCS pods to restart. You can verify (2) and (3) is as expected as the update rolls through the cluster.

Things to note:

It may take a few moments before the operator rolls out the new manifests. If it is done while the MCO is doing a MachineConfig update to the master pool, the manifests won't be updated until the master pool is finished updating. This is because of the way the operator's sync loops are structured.

The APIServer rejects the Modern profile at the moment, according to the docs.

If no tlsSecurityProfile is provided, the MCO will default to Intermediate.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

yuqi-zhang

Generally makes sense to me, will also let QE pre-merge verify (but other than security scanners, I don't think this really affects most end user directly, so mostly should be a safe change)

yuqi-zhang · 2024-07-12T23:27:34Z

+			return err
+		}
+		apiserverDir := filepath.Join(destDir, "api-server")
+		if err := os.MkdirAll(apiserverDir, 0o764); err != nil {


question: Hmm, I see we have this permission for some files, but I'm not really sure why we need execute and group write, etc.? Non-blocking though

I looked up the history on this and found these [1] and [2]. The folders get the owner execute bit, but the files don't. But, definitely agree that some updates could be done here. Perhaps a tech debt card?

yuqi-zhang · 2024-07-12T23:31:59Z

 	funcs["cloudPlatformAPIIntLoadBalancerIPs"] = cloudPlatformAPIIntLoadBalancerIPs
 	funcs["cloudPlatformAPILoadBalancerIPs"] = cloudPlatformAPILoadBalancerIPs
 	funcs["cloudPlatformIngressLoadBalancerIPs"] = cloudPlatformIngressLoadBalancerIPs
+	funcs["join"] = strings.Join


I for some reason thought the join function was native, just found this funny :)

there probably is some kind of weird printf incantation we can do here but this seemed cleaner since we already had existing custom functions

yuqi-zhang · 2024-07-23T23:25:20Z

There seems to be a conflict now

djoshy · 2024-07-24T12:54:38Z

rebased, but github seems asleep hmm

/tide refresh

djoshy · 2024-07-24T12:58:37Z

/shrug

djoshy · 2024-07-24T13:00:08Z

/test all

ptalgulk01 · 2024-07-25T14:55:21Z

pre-merge verified here in comment: https://issues.redhat.com/browse/MCO-850

djoshy · 2024-07-25T15:07:06Z

/payload 4.17 nightly blocking

openshift-ci · 2024-07-25T15:07:21Z

@djoshy: trigger 8 job(s) of type blocking for the nightly release of OCP 4.17

periodic-ci-openshift-release-master-ci-4.17-e2e-aws-ovn-upgrade
periodic-ci-openshift-release-master-ci-4.17-e2e-azure-ovn-upgrade
periodic-ci-openshift-release-master-ci-4.17-upgrade-from-stable-4.16-e2e-gcp-ovn-rt-upgrade
periodic-ci-openshift-hypershift-release-4.17-periodics-e2e-aws-ovn-conformance
periodic-ci-openshift-release-master-nightly-4.17-e2e-aws-ovn-serial
periodic-ci-openshift-release-master-ci-4.17-e2e-aws-ovn-upgrade
periodic-ci-openshift-release-master-nightly-4.17-e2e-metal-ipi-ovn-bm
periodic-ci-openshift-release-master-nightly-4.17-e2e-metal-ipi-ovn-ipv6

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/8f0807c0-4a97-11ef-834e-c188272dde38-0

djoshy · 2024-07-25T15:13:35Z

/test all

djoshy · 2024-07-25T17:20:04Z

/test e2e-gcp-op-techpreview

djoshy · 2024-07-25T17:33:59Z

/test e2e-gcp-op-techpreview

openshift-ci · 2024-07-25T19:18:18Z

@djoshy: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-vsphere-ovn-upi-zones	`963765e`	link	false	`/test e2e-vsphere-ovn-upi-zones`

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

yuqi-zhang · 2024-07-25T19:55:38Z

/lgtm

openshift-ci · 2024-07-25T19:55:58Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: djoshy, yuqi-zhang

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [djoshy,yuqi-zhang]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

openshift-bot · 2024-07-25T23:40:01Z

[ART PR BUILD NOTIFIER]

Distgit: ose-machine-config-operator
This PR has been included in build ose-machine-config-operator-container-v4.17.0-202407252246.p0.ge7692c8.assembly.stream.el9.
All builds following this will include this PR.

MCO-1202: MCO-1203: MCO-1204: MCO-1205: MCO-1213: Implementing tlsSecurityProfile for MCO

openshift-ci Bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 25, 2024

openshift-ci Bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 25, 2024

djoshy force-pushed the tls branch 2 times, most recently from 78910e3 to 3b6a0a7 Compare June 26, 2024 15:21

djoshy changed the title ~~[DNM] Testing global tls profile~~ MCO-1202: MCO-1203: MCO-1204: Implementing tlsSecurityProfile for MCO Jun 26, 2024

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jun 26, 2024

djoshy marked this pull request as ready for review June 26, 2024 20:31

openshift-ci Bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 26, 2024

openshift-ci Bot requested review from cdoern and dkhater-redhat June 26, 2024 20:32

djoshy changed the title ~~MCO-1202: MCO-1203: MCO-1204: Implementing tlsSecurityProfile for MCO~~ MCO-1202: MCO-1203: MCO-1204: MCO-1205: Implementing tlsSecurityProfile for MCO Jun 28, 2024

djoshy force-pushed the tls branch from 509bfd9 to 07f3044 Compare June 28, 2024 17:08

djoshy force-pushed the tls branch 3 times, most recently from e410dc4 to 74c2785 Compare July 2, 2024 20:41

djoshy changed the title ~~MCO-1202: MCO-1203: MCO-1204: MCO-1205: Implementing tlsSecurityProfile for MCO~~ MCO-1202: MCO-1203: MCO-1204: MCO-1205: MCO:1213: Implementing tlsSecurityProfile for MCO Jul 2, 2024

djoshy changed the title ~~MCO-1202: MCO-1203: MCO-1204: MCO-1205: MCO:1213: Implementing tlsSecurityProfile for MCO~~ MCO-1202: MCO-1203: MCO-1204: MCO-1205: MCO-1213: Implementing tlsSecurityProfile for MCO Jul 2, 2024

djoshy force-pushed the tls branch from 74c2785 to f681320 Compare July 3, 2024 15:39

yuqi-zhang approved these changes Jul 12, 2024

View reviewed changes

openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 23, 2024

djoshy added 5 commits July 24, 2024 08:48

operator/controller: grab tlsSecurityProfile

eb8a44f

add tls profile expansion for kube rbac proxy

bebc99e

server: apply tlsSecurityProfile via args

ab9b8e4

controller: consume bootstrap apiserver manifest

cd056f3

server: consume bootstrap apiserver manifest

963765e

openshift-ci Bot added the ¯\_(ツ)_/¯ ¯\\\_(ツ)_/¯ label Jul 24, 2024

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 24, 2024

djoshy force-pushed the tls branch from 67660d7 to 963765e Compare July 24, 2024 13:08

openshift-ci Bot assigned yuqi-zhang Jul 25, 2024

openshift-ci Bot added the lgtm Indicates that a PR is ready to be merged. label Jul 25, 2024

openshift-merge-bot Bot merged commit e7692c8 into openshift:master Jul 25, 2024

djoshy deleted the tls branch July 26, 2024 17:53

ptalgulk01 pushed a commit to ptalgulk01/machine-config-operator that referenced this pull request May 15, 2026

Merge pull request openshift#4435 from djoshy/tls

d3fb0b2

MCO-1202: MCO-1203: MCO-1204: MCO-1205: MCO-1213: Implementing tlsSecurityProfile for MCO

coderabbitai Bot mentioned this pull request Aug 2, 2026

WIP: Add TLS profile compliance e2e tests openshift/ingress-node-firewall#761

Closed

Uh oh!

Conversation

djoshy commented Jun 25, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci Bot commented Jun 25, 2024

Uh oh!

openshift-ci-robot commented Jun 26, 2024 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jun 26, 2024 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

djoshy commented Jun 27, 2024

Uh oh!

openshift-ci-robot commented Jun 28, 2024 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jun 28, 2024 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jun 29, 2024 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jul 2, 2024 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Jul 2, 2024 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

djoshy commented Jul 3, 2024

Uh oh!

openshift-ci-robot commented Jul 3, 2024 • edited by openshift-ci Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yuqi-zhang left a comment

Choose a reason for hiding this comment

Uh oh!

yuqi-zhang Jul 12, 2024

Choose a reason for hiding this comment

Uh oh!

djoshy Jul 15, 2024

Choose a reason for hiding this comment

Uh oh!

yuqi-zhang Jul 12, 2024

Choose a reason for hiding this comment

Uh oh!

djoshy Jul 15, 2024

Choose a reason for hiding this comment

Uh oh!

yuqi-zhang commented Jul 23, 2024

Uh oh!

djoshy commented Jul 24, 2024

Uh oh!

djoshy commented Jul 24, 2024

Uh oh!

djoshy commented Jul 24, 2024

Uh oh!

ptalgulk01 commented Jul 25, 2024

Uh oh!

djoshy commented Jul 25, 2024

Uh oh!

openshift-ci Bot commented Jul 25, 2024

Uh oh!

djoshy commented Jul 25, 2024

Uh oh!

djoshy commented Jul 25, 2024

Uh oh!

djoshy commented Jul 25, 2024

Uh oh!

openshift-ci Bot commented Jul 25, 2024

Uh oh!

yuqi-zhang commented Jul 25, 2024

Uh oh!

openshift-ci Bot commented Jul 25, 2024

Uh oh!

openshift-bot commented Jul 25, 2024

Uh oh!

Reviewers

Assignees

djoshy commented Jun 25, 2024 •

edited

Loading

openshift-ci-robot commented Jun 26, 2024 •

edited by openshift-ci Bot

Loading

openshift-ci-robot commented Jun 26, 2024 •

edited by openshift-ci Bot

Loading

openshift-ci-robot commented Jun 28, 2024 •

edited by openshift-ci Bot

Loading

openshift-ci-robot commented Jun 28, 2024 •

edited by openshift-ci Bot

Loading

openshift-ci-robot commented Jun 29, 2024 •

edited by openshift-ci Bot

Loading

openshift-ci-robot commented Jul 2, 2024 •

edited by openshift-ci Bot

Loading

openshift-ci-robot commented Jul 2, 2024 •

edited by openshift-ci Bot

Loading

openshift-ci-robot commented Jul 3, 2024 •

edited by openshift-ci Bot

Loading